Dev Daily 2026/6/5 — Rolldown 版 Vite 8 が定着、tsgo は TypeScript 7 へ最終調整

今日の全体像: ツールチェーンの Rust 化が同時多発で効いてきた

本日のフロントエンドと言語まわりの話題は、ひとつの流れに収束しています。それは「JavaScript で書かれていた開発ツールを、Rust や Go といったネイティブ言語で書き直す」動きが、いよいよ実用フェーズで体感差を生み始めた、という点です。

バンドラの vitejs/rolldown を中核に据えた Vite 8 が安定版になり、型チェックの microsoft/typescript-go が TypeScript 7 のリリース候補に到達しました。ビルドと型チェックという、フロントエンド開発で最も待たされる二つの工程が、同時期に大きく短縮される見通しになっています。

それぞれ単体でも大きなニュースですが、重要なのは「組み合わせたときの累積効果」です。保存のたびに走る型チェックと、確認のたびに走るビルドが両方速くなると、開発のフィードバックループ全体が短くなります。

Vite 8 と Rolldown: バンドラの一本化が意味すること

Vite はこれまで、開発時の依存事前バンドルに esbuild、本番ビルドに Rollup を使う二段構成でした。この構成は実績がある一方、開発と本番で挙動が微妙に分かれる「dev/prod の差」を生みやすいという課題がありました。

Vite 8 では、Rust 製の vitejs/rolldown を単一のバンドラとして採用し、この二段構成を一本化しています。狙いは大きく二つです。

• dev と prod の挙動を揃える: 同じバンドラを通すことで、開発時には問題なかったのに本番ビルドだけ壊れる、という事故を減らせます。
• ビルド時間の短縮: ネイティブ実装により、特にモジュール数の多い大規模アプリでまとまった短縮が報告されています。

移行の現実的な注意点として、プラグイン互換は重視されていますが、Rollup 固有 API に深く依存したプラグインや、内部実装に踏み込んだ独自設定では検証が必要です。アップグレード時はまず CI 上で本番ビルドを通し、出力物のサイズと内容を before/after で比較するのが安全です。

# 既存プロジェクトでの確認手順の一例
npm install vite@8
npm run build
# 出力サイズの差分を確認 (ツールは任意)
npx source-map-explorer "dist/assets/*.js"

数値は構成に強く依存します。本文中の「最大 -60%」はあくまで報告例の桁感であり、自分のプロジェクトでの実測を前提にしてください。

TypeScript 7 (tsgo): 型チェックという待ち時間への回答

言語側の主役は microsoft/typescript-go です。これは TypeScript コンパイラを Go へ移植したネイティブ実装で、tsgo という実行ファイルとして提供されてきました。本日、これが TypeScript 7 のリリース候補段階に入ったことが大きな話題になっています。

ポイントを整理します。

なぜ速いのか

従来の tsc は TypeScript 自身で書かれており、Node.js 上で動きます。ネイティブ移植版は Go で書かれ、並列処理を活かせる設計になっています。Microsoft は複数の公開リポジトリで型チェック時間が桁違いに縮んだと報告しており、エディタの初回起動やメモリ使用量の改善も大きいとされています。

バージョンの整理

ここは混同しやすいので押さえておきましょう。

• TypeScript 5.9: 従来の JavaScript ベース実装の流れにある安定版。
• TypeScript 6.0: JavaScript ベースとして最後のメジャー。7 への橋渡し。
• TypeScript 7.0: ネイティブ実装 (tsgo) ベース。高速化・省メモリ・並列性が主眼。

プレビューは @typescript/native-preview として配布されており、手元で tsgo を試せます。

# ネイティブ版を試す
npm install -D @typescript/native-preview
npx tsgo --noEmit

実務での向き合い方としては、まず CI の型チェックジョブで tsgo を並走させ、既存 tsc と結果が一致するかを比較するのが堅実です。挙動が完全一致するまでは tsc を正とし、速度メリットは「並走で先に気づける」形で享受するのが安全な移行戦略になります。

React Compiler と Biome: 「自動化」と「単一ツール化」

facebook/react の React Compiler は 19.2 で安定化し、いまは実運用のフェーズに入っています。手動の useMemo / useCallback を減らし、再レンダリングの最適化をコンパイラに任せる発想は定着しつつあります。次の焦点は、最適化追跡のために生成コードへ乗るオーバーヘッドを削り、出力バンドルをさらに軽くすることです。

一方、biomejs/biome は Lint と Format を 1 バイナリで完結させる方向で対応言語を広げています。ESLint + Prettier の二本立てを Biome 一本へ寄せる検討は引き続き根強く、関連する oxc-project/oxc を含め「JavaScript/TypeScript ツールチェーンを Rust で書き直す」潮流が一段とはっきりしてきました。

これらは個別の話に見えて、根は同じです。開発者が手で書いていた最適化や、複数ツールをつなぐ設定の手間を、高速なネイティブ実装へ吸収していく流れです。

まとめと、明日への目線

本日は「ビルド (Rolldown/Vite 8)」「型チェック (tsgo/TypeScript 7)」「最適化 (React Compiler)」「Lint+Format (Biome/oxc)」という、開発ループの主要工程が足並みをそろえてネイティブ化・自動化へ進んだ一日でした。

実務での次の一手としては、以下が現実的です。

1. 検証ブランチで Vite 8 へ上げ、本番ビルドの所要時間と出力サイズを計測する。
2. CI に tsgo を並走ジョブとして足し、tsc との結果差分を観察する。
3. React Compiler 導入済みなら、バンドルサイズの推移を継続記録する。

いずれも「いきなり置き換える」のではなく「並走させて差分を見る」ことから始めるのが安全です。各ツールのバージョンや数値は更新が速いため、導入判断の前には必ず一次情報 (公式ブログ・リリースノート) で最新状況を確認してください。