TypeScript 7.0 の数字はかなり派手です。公式の大規模 repo では、full build が TypeScript 6.0 より 7.7 倍から 11.9 倍速くなっています。
すぐ上げたくなる。自分も最初に見た時はそう思いました。
ただ、frontend の repo で最初に見るべきは速度じゃない。TypeScript 7.0 には、まだ stable な programmatic API がない。ここが移行の本体です。
tsc は TS7 にできても、typescript-eslint や framework の template tooling は TS6 の API を必要とすることがあります。typescript の version を一括で差し替えるより、compiler と周辺 tooling を分けて移した方が早い。
ここでは TS7 の tsc と TS6 の API を同じ repo に置き、速度と互換性を別々に確認します。
TS7 への移行は package 更新ではなく、実行経路の切り替え
frontend の TypeScript は、1 本の経路で動いているように見えて、実際には用途が分かれています。
TypeScript 7
└─ tsc / language server / project 全体の高速な型チェック
TypeScript 6
├─ compiler API を読む eslint plugin や独自 tool
└─ Vue / Svelte / Astro / Angular などの template tooling
TypeScript 公式も、7.0 の native compiler と @typescript/typescript6 を side-by-side で使う移行経路を案内しています。二重運用は逃げではなく、7.0 時点では正規の橋渡しです。
ここを無視して typescript だけ TS7 にすると、tsc は速くなったのに lint や framework build が壊れる、という微妙な状態になります。compiler の benchmark と ecosystem の互換性は、最初から別のチェック項目にしておくのがよいです。
npm alias で TS7 と TS6 を同居させる
最小構成はこうです。
{
"devDependencies": {
"@typescript/native": "npm:typescript@^7.0.2",
"typescript": "npm:@typescript/typescript6@^6.0.2"
},
"scripts": {
"typecheck": "tsc --noEmit -p tsconfig.json",
"typecheck:ts6": "tsc6 --noEmit -p tsconfig.json",
"lint": "eslint ."
}
}
-
tsc: TS7 の native compiler -
tsc6: 比較用の TS6 compiler -
typescript: compiler API を読む既存 tool 向けの TS6 package
install したら、解決先を見ます。
npx tsc --version
npx tsc6 --version
npm ls @typescript/native typescript @typescript/typescript6
そのまま実行経路を分けて通します。
npm run typecheck
npm run typecheck:ts6
npm run lint
npm run build
typecheck が通っても、まだ半分です。eslint が TS6 API を読めるか。framework build はどちらの binary を起動するか。editor の template 診断は動くか。ここは別々に見ます。
lockfile も commit します。local では alias が通ったのに CI で別 version が解決された、では比較になりません。
先に TS6 の default 変更を片付ける
TS5.9 から TS7 へ一気に上げて error が増えた時、その原因を native port だと決めつけるのは危険です。TypeScript 6.0 由来の default 変更が混ざっています。
特に frontend で踏みやすいのが noUncheckedSideEffectImports です。
import "./styles.css";
CSS module の型宣言や bundler 側の ambient declaration が足りない repo では、今まで見逃されていた import が error になります。
たとえば、まずは project の方針に合わせて declaration を用意します。
// src/env.d.ts
declare module "*.css";
ただし、これを雑に追加して終わりにはしません。CSS Modules で class 名まで型付けしているなら、その仕組みを残したまま直します。
strict、types、rootDir などの差も同様です。自分なら次の順番で切ります。
1. TS5.9 と TS6 の error 差分をなくす
2. TS6 と TS7 の型チェック結果を比べる
3. その後で実行時間と memory を比べる
互換性の差と速度の差を同じ PR に押し込むと、何が原因で壊れたのか分からなくなります。
benchmark は cold / warm と memory を一緒に取る
公式の「約 10 倍」は目を引きます。でも、その倍率を自分の repo の見積もりにそのまま入れるのは無理があります。
約 1,700 行の React + Vite app を比較した国内の検証では、warm の Total time が TS5.9 の 0.42 秒から TS7 の 0.052 秒まで縮んでいます。ただ、小規模 repo では --checkers 4 や --checkers 8 に増やしても速くならず、8 では memory が増えました。
CPU を盛る前に、基準値を残しておきます。
# cold: incremental cache を消して測る
rm -f .tsbuildinfo
/usr/bin/time -l npm run typecheck
# compiler 内訳
npx tsc --noEmit -p tsconfig.json --extendedDiagnostics
# warm: cache を消さず、同じ command を複数回実行する
/usr/bin/time -l npm run typecheck
/usr/bin/time -l npm run typecheck
macOS の /usr/bin/time -l では maximum resident set size も確認できます。Linux なら /usr/bin/time -v に置き換えます。
自分なら、この表をそのまま検証メモにします。
| 項目 | 見たいこと |
|---|---|
| Total time / Check time | 日常の feedback loop が本当に縮んだか |
| Memory used / Max RSS | local と CI runner の上限に収まるか |
| cold / warm | cache の効き方を速度向上と混同していないか |
| error 数と内容 | TS6 migration error と TS7 差分を分離できているか |
--checkers を増やせば速くなる、とは限りません。小さい repo や CPU の少ない CI runner では overhead が勝つことがあります。実際に使う runner と同じ core 数で決めます。
framework build は別枠で確認する
tsc --noEmit と Next.js / Vite / Vue / Svelte / Astro の build は別物です。
たとえば 2026-07-11 時点の Next.js 導入例では、stable 版の path の扱いで next build が失敗し、canary の experimental.useTypeScriptCli を試しています。これは移行境界を理解するにはよい例ですが、今後も固定で使う設定だとは限りません。
記事を読んだ時点の canary 設定を、そのまま team の恒久設定にしない方がいいです。現在の Next.js release と公式 docs を確認し、検証 branch だけで試します。
npm run typecheck # TS7 CLI
npm run lint # TS6 API を使う経路
npm run build # framework 自身の TypeScript 経路
Vue や Svelte なら template 内の型 error、Astro なら .astro、Angular なら template type checking も開いて確認します。terminal の tsc が速くなっても、editor で補完や診断が消えたら開発体験は改善していません。
移行判定は経路ごとに出す
自分なら、移行 PR にこの表を貼ります。
| 経路 | TS7 に進める | TS6 に残す |
|---|---|---|
| CLI type check | error が一致し、時間か memory が改善 | TS6 migration error が残っている |
| eslint / API tool | TS7 API 対応を確認済み |
typescript package の API が必要 |
| editor / template | LSP と plugin の動作を確認済み | embedded language tooling が TS6 依存 |
| CI | 本番 runner で改善を再現 | worker 増加で時間や RSS が悪化 |
全部を同じ日に TS7 へ移す必要はないです。
やることは地味です。tsc を横に置く。型チェックの結果が揃ったら、local と CI で時間を測る。API や template tooling は、対応状況を見ながら後で切り替える。
TypeScript 7 の価値は、benchmark の倍率そのものではなく、編集してから型 error が返るまでの待ち時間が短くなることです。そこが自分の repo で縮んだか。移行判断は、その数字で十分です。
Source notes
- TypeScript 公式: Announcing TypeScript 7.0
- Next.js / typescript-eslint で TS7 と TS6 を併用した例: TypeScript 7.0（ネイティブ版）をNext.jsに導入してみた
- React + Vite で TS5.9 / 6.0 / 7.0 を比較した例: TypeScript 5.9 / 6.0 / 7.0 を実プロジェクトで比較してみた