- 従来の esbuild + Rollup の二重構成 を Rust ベースのバンドラ Rolldown に一本化し、最大10〜30倍高速なビルド性能を実現
- 新しい プラグインレジストリ が公開され、Vite・Rolldown・Rollup プラグインの検索・管理が可能
- Vite Devtools、TypeScript パス解決、Wasm SSR、コンソールフォワーディング など、開発を便利にする機能が追加
- 今回のリリースは Vite エコシステムにおける最大級の構造的変化 であり、今後の統合ツールチェーン発展の基盤となる
Rolldown ベースの Vite 8
- Vite 8 は、従来の esbuild（開発用） と Rollup（本番用） の二重バンドラ構成を Rolldown 単一バンドラ に統合
- Rolldown は Rust で書かれた高性能バンドラ で、Rollup と同じプラグイン API をサポート
- 既存の Vite プラグインの大半が追加修正なしで動作
- 性能 は Rollup 比で 10〜30 倍高速で、モジュール単位キャッシュ、柔軟なチャンク分割、Module Federation などの高度な機能をサポート
Rolldown 導入の過程
- 初期には
rolldown-vite パッケージとして技術プレビューを提供し、コミュニティからフィードバックを収集
- さまざまな実際のコードベースでテストし、互換性の問題を解決
- 主要プラグインとフレームワークを対象とした 専用 CI テスト体制 を構築
- 2025年12月に Vite 8 ベータ を公開し、Rolldown を完全統合
- ベータ期間中に Rolldown は Release Candidate 段階 へ進み、安定化が進んだ
実際の性能改善事例
- 複数の企業が ビルド時間短縮効果 を報告
- Linear: 46秒 → 6秒
- Ramp: 57% 短縮
- Mercedes-Benz.io: 最大 38% 短縮
- Beehiiv: 64% 短縮
- 大規模プロジェクトほど効果が顕著であり、Rolldown の継続的な改善も予告されている
統合ツールチェーンと技術スタック
- Vite 8 は Vite（ビルドツール）、Rolldown（バンドラ）、Oxc（コンパイラ） が緊密に連携する エンドツーエンドのツールチェーン へ進化
- 解析・変換・最適化の全工程で一貫性を確保
- Oxc の意味解析 を活用した ツリーシェイキング最適化 が可能
- 新しい JS 仕様を迅速に導入できる構造
追加機能
- Vite Devtools: 開発サーバー上でプロジェクトの状態を視覚的に分析可能
- TypeScript パス（alias）の自動解決 および emitDecoratorMetadata の組み込みサポート
- Wasm SSR: サーバーサイドレンダリング環境で
.wasm?init インポートをサポート
- ブラウザコンソールフォワーディング: ブラウザエラーをターミナルへ転送し、デバッグ効率を向上
- @vitejs/plugin-react v6: Babel を削除し、Oxc ベースの React Refresh を適用、インストール容量を削減
今後の開発方針
- Full Bundle Mode（実験的）: 開発中もバンドリングを実行し、3倍高速なサーバー起動、40% 高速なリロード、10倍少ないネットワークリクエスト を実現
- Raw AST 転送 および Native MagicString 変換 により、Rust と JS 間の性能差を縮小
- Environment API 安定化 に向けたエコシステムとの協業を進行中
インストール容量の変化
- Vite 8 は Vite 7 より約 15MB 増加
- lightningcss（約 10MB）: デフォルトの CSS 圧縮機能を提供
- Rolldown バイナリ（約 5MB）: 速度最適化のため容量が増加
- 今後のリリースでも容量最適化を継続予定
マイグレーションガイド
- ほとんどのプロジェクトは 設定変更なしでアップグレード可能
- 既存の
esbuild および rollupOptions 設定は自動変換
- 大規模プロジェクトでは 2段階マイグレーション を推奨
- Vite 7 で
rolldown-vite へ切り替えた後、Vite 8 にアップグレード
- 詳細な手順は公式の Migration Guide と Changelog で確認可能
Rollup と esbuild への謝辞
- Rollup は Vite のプラグインエコシステムの基盤を提供し、Rolldown はその API を継承
- esbuild は高速な開発体験を可能にした中核技術であり、Rust・Go ベースのツーリング発展の契機となった
- 両プロジェクトの貢献は Vite の DNA に深く刻み込まれている
コミュニティと協力
- Vite 8 の開発は sapphi-red と Vite チーム、Rolldown チーム、そして多数のコミュニティ貢献者の協力によって完成
- VoidZero、Bolt、NuxtLabs が主要パートナーとして参加
5件のコメント
Hacker Newsの意見
業界が「ビルドはもともと時間がかかるものだ」と何の疑いもなく使ってきた非効率なツール群に、どれほど多くの計算資源を浪費してきたのかを改めて考えさせられる
私たちはその遅いビルドに合わせて予定を組み、休憩時間を冗談のように扱い、キャッシュレイヤーまで構築してきた
Viteのメンテナーたちに賛辞を送りたい
ほとんどの本番ソフトウェアは必要以上に何十倍も遅い
Electronアプリが数GBのRAMを使いながら、40年前のソフトウェアよりもさらにもたつく現実がその証拠だ
14年前、ビルド待ちで失われる時間に気づき、とくにJavaエコシステムでこの問題が深刻だと感じた
昔、Rubyプロジェクトでは統合テストが毎回DBを作り直すために10分ずつかかっていた
Kotlin/Spring Bootもコンパイルは遅いし、Rustコンパイラも速いとは言えない
ただしテストは私たちが制御できる。単体テストはミリ秒単位で終わるべきで、統合テストは並列化とデータのランダム化によって大きく改善できる
私はMacBook ProでRedis、DB、Elasticsearchを含む数百件のSpring統合テストを40秒以内で回している
こうした設定を一度整えれば、速いフィードバックループが生まれ、開発の楽しさが戻ってくる
私がVite 8に貢献した部分はWasm SSRサポートだった
.wasm?initインポートがSSR環境でも動作するように拡張した過程は遅かったが、チームが細かく助けてくれ、ドキュメントまで追加してくれた点が印象的だった
Viteチームが単にツールを作っているだけでなく、コントリビューターの育成と協業にも本気だと感じられる
Electron時代にこうした性能向上を見られるのは本当にうれしい
私が長く保守してきたプロジェクト（React hooks以前から始まったもの）は、以前はWebpackベースのreact-scriptsでビルドに2分かかっていた
今ではVite 8で1秒で終わる。私たちがどれほど多くのリソースを浪費してきたかを示す事例だ
ブラウザがそのまま実行できるべきで、TypeScriptも型だけ取り除けばすぐ実行できるように設計されていた
こうしたビルドツールの存在自体が間違った方向に思える
私たちのチームはVite 8導入後、ビルド時間が4分から30秒に減った
ほぼドロップイン置き換えのレベルで、Viteチームに感謝している
Viteに統合される前から使っていたが、本当に素晴らしい
Nextより速いと言われているのに、そのレベルなら相当な規模なのだろう
特定のフレームワークに縛られないオープンソースのバンドリングソリューションを作ったViteチームに感謝したい
（軽く咳払いしながらTurbopackに言及）
素晴らしいニュースだ。だがNext.jsはこうしたコミュニティの成果を享受できない気がする
VercelのNIH症候群のせいだ
Next 13でTurbopackアルファを始め、Next 16でようやくデフォルトにした
2022年にはViteとの比較ベンチマークも歪められていた
キャッシュ問題、遅い性能、RSCのセキュリティ脆弱性、分かりにくいApp Router、Vercel以外でのホスティングの不便さなど
Next.jsを選ぶのはリスクだ
関連リンク: 比較議論, キャッシュの歴史, 性能分析, セキュリティCVE, OpenNext
公式ドキュメントでもNextがデフォルトのように言及されるのは奇妙だ
Reactを非SPAとして使う理由が分からない
例: Sitecore Cloud, Sanity, Contentful など
Vite+、Void Cloud、Void Frameworkなどによって、
いよいよVercelとVoidの対決が始まりそうだ
とくにPRC(Server Functions)のデモが興味深い — DBからUIまでエンドツーエンドの型安全性を示している
私たちはTelefunc（tRPC代替）でRPC設計を研究しており、Voidチームとの協業に期待している
関連リンク: PRCデモ動画, Telefunc, Vike
Void CloudはCloudflare Workers上に構築されているようで、現時点では情報が少ない
それでもVite+をMITオープンソースとして公開するというのは非常に心強い
BunがAnthropic支援に集中するあまりOSSをおろそかにすれば、競争優位を失うかもしれない
参考: Void Cloud
JSエコシステムが混乱していても、Viteは一貫して優れたDXと本番品質を示している
統合されたRolldownバンドラによって、さらに高速で柔軟な基盤になるだろう
1998年からWeb開発をしてきた立場として、本当にファンだ
長期保守を重視して、私はesbuildを直接使っている
Viteのようなラッパーが内部変更で壊れるたびに修正するのが嫌だからだ
Zodで型検証を処理し、Postgres型だけコード生成していた
次ならKyselyを使っていたと思う
tsconfig pathsの組み込みサポートは本当に良いQoL改善だ
設定の重複を減らせる
プロジェクトによってはそのほうがシンプルかもしれない
実際、JS はもともとビルド工程が不要な言語だったはずで、ブラウザがそのまま実行できるべきだし、TypeScript も型だけ除去すればすぐ実行できるように設計されていたはずです。こうしたビルドツールの存在自体が間違った方向に思えます → これをどうすれば正常化できるのでしょうか;
ブラウザでしか動かしていなかったものをサーバーで直接動かすようになったので、避けられない流れだった気がします
私は、Webアプリが高度化するにつれて生じた自然な現象だと考えています。
たぶん、Flashを捨てたときのように、ブラウザのJSも捨てるべきではないでしょうか？ でも、JSが捨てられる気配は見えません。