tsrsとは、TypeScript 7のコンパイラ(tsc)と言語サーバーをRustへ移植したオープンソースのツールで、2026年10月20日にCloudflareとVoidZeroが発表しました。tsconfig.jsonをそのまま読み、同じ診断をより短い時間と少ないメモリで返すことを狙っています。本記事では、2026年10月28日時点の最新版0.20.1-ts7.1.0-betaを前提に、インストールと型チェックの手順、–fastなどのオプション、ベンチマーク数値の読み方、準拠テストの通過件数と未対応機能、CIでtscと並走させる設定例、そして今採用すべきかの判断基準を、公式リポジトリの記述に沿って解説します。
まとめ:tsrsはCIで並走させて測り、型チェックの判定はtscに残す
tsrsはTypeScriptのフォークではなく、Go製のTypeScript 7を関数単位でRustへ写した移植版です。診断・メッセージ・終了コードがtscとずれたら、それはtsrs側のバグとして扱われます。
速さは本物に近いものの、版番号にbetaが付き、言語サーバーの互換テストは1割ほど未通過です。今やるべきことは、CIでtscの横にtsrsを並べて所要時間と診断差分を記録することまでにとどまります。
合否の判定、JavaScriptの出力、エディタ連携の置き換えは、TypeScript 7.1準拠の安定版が出てから判断します。
tsrsとは何か、TypeScript 7のGo実装をRustへ移した移植版の位置づけ
tsrsを理解する近道は、TypeScript 7との関係を押さえることです。7はコンパイラをGoで書き直したネイティブ版で、tsrsはそのGo実装をさらにRustへ移しています。
Cloudflare・VoidZero・Owner.comのOxc移植と非フォーク方針
Cloudflareの発表記事によると、tsrsはCloudflare、VoidZero、Owner.comのMax Schwenk氏が協力し、RustでJavaScriptツールを作るOxc(Rust製JavaScriptツールチェーン)の一部として育てています。言語仕様の決定権はTypeScriptチームに残し、移植版は元の実装に厳密に従う、とも明言されました。
Goで十分速いのにRustへ移す理由として、記事はWebAssemblyを挙げています。GoをWasmにするとガベージコレクタを同梱する必要がありますが、Rustならホストとのメモリ受け渡しが単純になるためです。ライセンスはApache-2.0で、GitHubのREADMEはMicrosoftの提携・承認を受けたものではないと注記しています。
0.20.1-ts7.1.0-betaの版番号と追従先TypeScriptの確認方法
npmに公開されたtsrsの版番号は、前半がtsrs自身の版、「ts」以降が追従しているTypeScriptの版を表します。0.20.1-ts7.1.0-betaなら、tsrs 0.20.1がTypeScript 7.1.0-betaの挙動を写していることになり、0.18.0までは7.1の開発版(dev.20260929)を追っていました。
比べる相手のtscも同じ7.1 betaにそろえないと、診断差分がtsrsのバグなのか版の差なのか見分けられません。2026年10月28日時点でtypescriptのnpm上のlatestは7.0.2、betaタグが7.1.0-betaです。TypeScript 7本体の変更点と移行手順はTypeScript 7.0の仕組みと6.xとの使い分けで、RCから正式版までの経緯はTypeScript 7とtsgoの移行の要点で扱っています。
tsrsをインストールしてnoEmitで型チェックを試す手順とCLIオプション
tsrsはtscの置き換えとして作られているため、既存のtsconfig.jsonを書き換えずに試せます。違いが出るのはtsrs独自の高速化オプションと、動く環境の範囲です。
pnpmで版を固定して入れ、tsconfig.jsonのまま型チェックを流す
公式のUSAGE.mdは版を固定したインストールを例示しています。比較用に同じ7.1 betaのtypescriptも入れ、型チェックだけを流す場合に付けるのが--noEmitです。付けないとtscと同様にJavaScriptと宣言ファイルを出力します。
# tsrsと、比較相手のTypeScript 7.1 betaを開発依存に入れる
pnpm add -D [email protected] [email protected]
# 型チェックだけを実行(tsconfig.jsonはそのまま読まれる)
pnpm exec tsrs -p . --noEmit
# 高速プリセットを有効にし、件数と所要時間も表示する
pnpm exec tsrs -p . --noEmit --fast --extendedDiagnostics
# プロジェクトに入れずに一度だけ試す
pnpm dlx [email protected] -p . --noEmit
strict、skipLibCheck、noCheckなどの設定はtsconfig.jsonの値どおりに扱われます。READMEの例はpnpmですが、npmのnpx tsrsでも同じバイナリが動きます。
tsrsの高速化・並列数・メモリ上限オプションと環境変数の使い分け
既定のtsrsは、チェッカーの数(既定4)などをTypeScriptと同じ設定に固定して動きます。–fastは0.20.0で入った高速プリセットで、マシンに合わせてチェッカー数を変え、キャッシュを足します。
| オプション | 役割 | 注意点 |
|---|---|---|
--fast |
高速プリセットを有効化 | tscとの完全一致は保証外 |
TSRS_FAST=1 |
–fastを環境変数で有効化 | 値は1のみ有効・フラグが優先 |
--checkers N |
チェッカーのスレッド数 | 既定は4 |
--maxMemory 12G |
使用メモリを指定値付近に抑える | –fastかつ–noEmit時のみ |
--singleThreaded |
単一スレッドで実行 | メモリの小さいCIランナー向け |
–fastはtscと診断の順序がずれる余地を公式が認めています。差分を比べる用途では既定モードを使い、速さを測る用途で–fastを足す、と分けておくと結果を読み違えません。
Windowsとwasm版で使えない機能、対応するネイティブバイナリの範囲
npmのtsrs 0.20.1が用意するネイティブバイナリは、Windows x64、macOS(x64・arm64)、Linux(x64・arm64のglibcとmusl)の7種類です。Windows on Armは含まれていません。
COMPATIBILITY.mdでは、–watchはLinuxとmacOSのみ対応で、Windowsでは未対応として終了すると明記されています。WebAssembly版の@tsrs/wasmはNode.js 22以上が必要で、シングルスレッド動作です。開発者のPCがWindowsでも、CIのLinuxランナーで動かす分には影響しません。
tsrsのベンチマーク数値の読み方、最大8倍と2〜6倍の差を確かめる
tsrsの速さは「最大8倍」と紹介されることが多いものの、比較の基準をそろえると数字は小さくなります。採用判断には自分のリポジトリでの実測が要ります。
発表値の基準はTypeScript 7.0、RESULTS.mdの基準は7.1 beta
Cloudflareの「最大8倍速・メモリ約70%減」は、同じワーカー数でTypeScript 7.0と比べた値です。一方、TypeScript 7.1 betaの公式発表では、7.1 beta自体が7.0より1.2〜1.9倍速くなっており、その処理速度を高めるために行った改善の一部はtsrsから取り込まれたとCloudflare側が説明しています。
7.1 betaと比べた公式ベンチマーク(2026年10月27日・Apple M3 Max 14コア・36GB)の抜粋が次の表です。
| プロジェクト | 7.1 beta | tsrs | tsrs –fast | ピークメモリ(7.1 beta→tsrs) |
|---|---|---|---|---|
| t3code-server | 7.12秒 | 1.70秒 | 1.19秒 | 4.38GiB→1.82GiB |
| vscode | 5.08秒 | 1.98秒 | 0.85秒 | 5.48GiB→2.36GiB |
| mikro-orm | 4.60秒 | 1.37秒 | 0.70秒 | 4.15GiB→1.60GiB |
| date-fns | 0.31秒 | 0.16秒 | 0.13秒 | 406MiB→182MiB |
19件の倍率は既定で1.94〜4.19倍、–fastで1.90〜6.56倍、メモリは1.85〜2.60分の1でした。小さいプロジェクトほど倍率が下がる傾向も読み取れます。
自分のリポジトリで–extendedDiagnosticsを使い所要時間を計測する
計測は、同じマシンで同じtsconfig.jsonに対し、7.1 betaのtscとtsrsを交互に3回以上流して中央値を取ります。公式ベンチマークも10回(TypeScriptは5回)の中央値です。
# 7.1 betaのtscとtsrsを同条件で3回ずつ実行し、所要時間を比べる
for i in 1 2 3; do
/usr/bin/time -p pnpm exec tsc -p . --noEmit --extendedDiagnostics > /dev/null
/usr/bin/time -p pnpm exec tsrs -p . --noEmit --extendedDiagnostics > /dev/null
done
見るのは実時間(real)と最大メモリです。型チェックが元から10秒未満なら、数倍速くなっても開発体験はほとんど変わりません。逆に1分を超えるリポジトリでは、CIの待ち時間とランナーのメモリ上限の両方に効いてきます。
tsrsの互換性の現状、準拠テストの通過件数と未対応オプションを確認する
tsrsはGo実装を仕様とみなし、差があればtsrsのバグとして直す方針です。どこまで一致しているかは、COMPATIBILITY.mdの件数で確かめられます。
型チェック13,700件一致とLSP 4,092/4,562件が示す成熟度の差
0.20.1時点の準拠テストでは、型チェックのエラーbaselineが13,700件一致し、JavaScriptと宣言ファイルの出力も13,626件で照合されています。CLIの型チェックは、すでにtscとほぼ同じ結果を返す段階にあります。
差が残るのはその外側です。言語サーバーのFourslashテストは4,562グループ中4,092(約9割)、tscの–buildは223件中191件、tscWatchは42件中39件の通過でした。Node APIは177メソッド中170で成功応答を返します。コンパイラAPIを使う自作ツールを持つ場合は、TypeScript Compiler APIの使い方とTypeScript 7対応と照らして、使っているメソッドが残り7件に入っていないかを先に確かめます。
–init・–locale・コンテンツマッパーなど、移行前に洗い出す未対応機能
次の機能は0.20.1時点で使えないか、挙動がtscと異なります。CIのスクリプトやエディタ設定で使っていないかを、導入前に洗い出しておきます。
--initと--showConfigは未対応で、指定すると終了する--localeは無視され、エラーメッセージは英語のみ- .vue・.svelte・.astroのコンテンツマッパーは、CLIでは動くが言語サーバーでは未対応
--generateTraceは未対応で、警告を出してトレースなしで型チェックする
ES5ターゲットやAMD、baseUrlといったTypeScript 7で削除された設定は、tsgoと同じく拒否されます。6.x以前の設定を引きずっている場合は、baseUrl非推奨(TS5101)の直し方のような7系への移行作業が先に必要です。
CIの型チェックだけtsrsへ並走させるGitHub Actionsの設定例と運用
tsrsを試すなら、合否を決めるtscはそのまま残し、横でtsrsを流して差分と時間を記録する形が安全です。並走で落ちても、プルリクエストのマージは止まりません。
tscを判定に残し、tsrsの診断差分を成果物に記録するワークフロー
次のワークフローは、tscで合否を判定したあと、tsrsを並走させて両者の診断を並べ替えて比べ、差分ファイルを成果物として残します。GitHub Actionsのrunはpipefail付きのbashで動くため、エラーで止めたくない行には|| trueを付けています。
# .github/workflows/typecheck.yml
name: typecheck
on: [pull_request]
jobs:
typecheck:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: pnpm/action-setup@v4
- uses: actions/setup-node@v4
with:
node-version: 22
cache: pnpm
- run: pnpm install --frozen-lockfile
# 合否の判定はこれまでどおりtscで行う
- name: tsc
run: pnpm exec tsc -p . --noEmit
# tsrsは並走のみ。失敗してもジョブは落とさない
- name: tsrs shadow
if: always()
continue-on-error: true
run: |
pnpm exec tsc -p . --noEmit --pretty false | sort > tsc.txt || true
time pnpm exec tsrs -p . --noEmit --pretty false | sort > tsrs.txt || true
diff -u tsc.txt tsrs.txt > diag.diff && echo "diagnostics match" || echo "diagnostics differ"
- uses: actions/upload-artifact@v4
if: always()
with:
name: typecheck-diff
path: diag.diff
差分比較のステップでは–fastを付けていません。–fastは診断順序の一致を保証しないため、並べ替えても余計な差分が混ざる可能性があるからです。速さだけを見たい週は、別ジョブで–fastを付けて時間を記録します。
診断差分が出たときの切り分け手順とIssueに添える最小再現
diag.diffに差分が出たら、まずtscとtsrsの追従先が同じ7.1.0-betaかを確かめます。版がそろっていて差が残るなら、該当ファイルだけを含む小さなtsconfig.jsonを作り、差が再現する最小のコードまで削ります。
tsrsのリポジトリはプルリクエストを受け付けておらず、不具合はIssueで報告する運用です。READMEは最小の再現手順を添えるよう求めています。報告まで済ませておけば、安定版で直ったかどうかを同じ再現コードで確かめられます。
tsrsを今使う場面と見送る場面、採用条件を規模と運用体制で言い切る
tsrsの採否は、型チェックにかかる時間と、ツール側の不具合を自分たちで切り分けられる体制があるかで決まります。2026年10月時点の結論は次のとおりです。
型チェックに1分以上かかるモノレポは、CIでの並走から始める
CIの型チェックが1分を超える、ランナーのメモリ不足で落ちることがある、という2条件のどちらかに当てはまるなら、前章のワークフローで並走を始めます。公式ベンチマークでピークメモリが半分以下になっているため、メモリ起因の失敗には特に効く見込みがあります。
並走で2〜4週間、差分ゼロが続いたら、開発者の手元でpre-commitの型チェックだけtsrsに切り替える判断材料になります。Oxlintの型認識ルールへの統合もCloudflareが試すと表明しており、OxlintとESLintの違いで触れたlint側の高速化と組み合わせる余地もあります。
本番CIの合否判定・出力・エディタ連携は安定版まで置き換えない
型チェックが10秒未満で終わる中小規模のプロジェクトでは、tsrsは導入しません。数秒の短縮のために、beta版の挙動差を追う運用負担を背負う理由がないからです。
規模が大きくても、CIの合否判定、本番ビルドのJavaScript出力、VS Codeの言語サーバーは、TypeScript 7.1に100%準拠した安定版が出るまでtscとtsgoのままにします。言語サーバーの互換テストが約1割未通過という数字は、エディタの補完やリファクタリングで挙動の差が生じる可能性が残っているという意味です。大規模なTypeScript資産の型チェック時間やビルド構成の見直しを、移行計画から含めて外部に任せたい場合は、一創のフルスクラッチのWebシステム開発で相談を受け付けています。
よくある質問
tsrsについて、検索でよく調べられている疑問に回答します。
tsrsとtsgo(TypeScript 7)の違いは何ですか?
tsgoはMicrosoftのTypeScriptチームがGoで書き直した公式のネイティブ版で、TypeScript 7として正式に提供されています。tsrsはそのGo実装をRustへ移した第三者の移植版で、CloudflareとVoidZeroが中心になって開発しています。挙動はtsgoと一致させる方針で、両者に差があればtsrs側のバグという扱いです。言語の仕様を決めるのは引き続きTypeScriptチームです。
tsrsは本番のビルドで使えますか?
2026年10月28日時点の最新版は0.20.1-ts7.1.0-betaで、安定版はTypeScript 7.1に100%準拠した時点で出す予定とされています。型チェックの準拠テストは13,700件一致していますが、–buildや言語サーバーには未通過のテストが残っています。本番の合否判定は当面tscに残し、CIでの並走にとどめるのが安全です。
tsrsはWindowsで動きますか?
Windows x64向けのネイティブバイナリは提供されており、型チェックは実行できます。ただし–watchはWindowsでは未対応で、Windows on Arm向けのバイナリもnpmにありません。WebAssembly版の@tsrs/wasmならNode.js 22以上で動きますが、シングルスレッドのため速さはネイティブ版に劣ります。CIをLinuxで回す構成なら制約はほぼありません。
tsrsとts-rsは同じものですか?
別物です。ts-rsはRustの構造体からTypeScriptの型定義ファイルを生成するRustのライブラリ(クレート)で、名前が似ているため検索結果に混ざります。本記事で扱うtsrsは、TypeScriptのコードを型チェックするコンパイラの移植版で、npmのパッケージ名もtsrsです。GitHubではoxc-project/tsrsのリポジトリで開発されています。
tsrsとOxcやOxlintはどう関係していますか?
tsrsは、Rust製のJavaScriptツール群であるOxcプロジェクトの一部として開発されています。パーサーやリンターのOxlintと同じ傘の下にあり、Cloudflareの発表ではOxlintの型認識ルールにtsrsを組み込む試みも予定に挙がっています。現時点ではOxlintとは別のパッケージであり、インストールして使う対象はtsrs単体です。
関連記事
- TypeScript 7.0とは?Goネイティブ移植で型チェックを約10倍速くする仕組みを解説:tsrsの移植元であるTypeScript 7本体の解説。
- TypeScript 7とは?Go製ネイティブコンパイラtsgoで最大10倍高速化|RC公開と移行の要点:tsgoの配布と移行手順。
- Oxcとは?Rust製JavaScriptツールチェーンの構成と使い方・SWCとの違い:tsrsを抱えるOxc全体の構成。
- Vite+とは?vpコマンドの使い方と1.0の中身・既存Vite案件の移行手順を実装目線で解説:VoidZeroが手がける開発ツール群の現状。
- TypeScript 6.0とは|5から6への移行手順とts5to6・7.0との違い:7系とtsrsへ進む前の6.0移行。