デュアルバンドラ構成、正直キツかった話
2026年3月12日、Vite 8.0が正式リリースされました。Vite 2以来、最大のアーキテクチャ変更と公式がうたうこのリリースを、実際に手元のプロジェクトで試してみました。
まず前提として、私たちRagateではフロントエンド開発にViteを積極的に採用しています。React + TypeScriptの構成が多く、Viteの高速な開発体験にはずっと助けられてきました。
ただ、以前から一つ引っかかっていたことがあります。Viteは開発時にesbuild、本番ビルドにRollupというデュアルバンドラ構成を採用していました。これ、大半のケースでは問題なく動くんですが、たまに「開発では動くのに本番ビルドでコケる」という現象に遭遇するんですよね。
具体的には、esbuildとRollupでモジュール解決の挙動が微妙に異なるケースがありました。特にCSSモジュールの扱いや、一部のサードパーティライブラリのCommonJS/ESM混在モジュールの解決で、開発と本番で挙動が違うことが何度かありました。そのたびに「これはesbuild側の問題か?Rollup側か?」と切り分けるのが地味に面倒で、ぶっちゃけ開発チーム内でも「Viteの二刀流バンドラ、もうちょっとなんとかならないかな」という声は上がっていました。
Vite公式も同じ課題認識を持っていたようで、公式ブログでは「2つの変換パイプラインが2つのプラグインシステムを意味し、それらを同期させるためのグルーコードが増え続けていた」と率直に振り返っています。
そんな中でのVite 8.0。Rustベースの新バンドラ「Rolldown」で開発・本番を統一する、というニュースを見たとき、正直「やっと来たか」と思いました。
Vite 8.0 の概要!Rolldownとは何か

Rolldownの基本
Rolldownは、VoidZeroチームが開発したRustベースのバンドラです。VoidZeroはViteやVue.jsの生みの親であるEvan You氏が2024年に設立した企業で、JavaScriptツールチェーンの統合を目指しています。
Rolldownの設計目標は明確で、以下の3つです。
設計目標 | 詳細 |
|---|---|
パフォーマンス | Rustで記述されており、ネイティブ速度で動作。ベンチマークではRollupの10〜30倍高速で、esbuildに匹敵する性能 |
互換性 | RollupおよびViteと同じプラグインAPIをサポート。既存のViteプラグインの大半がそのまま動作する |
高度な機能 | フルバンドルモード、柔軟なチャンク分割、モジュールレベルの永続キャッシュ、Module Federationサポートなど、デュアルバンドラでは困難だった機能を実現 |
統合ツールチェーンとしてのVite 8
Vite 8.0では、Rolldownの内部でOxcというRust製コンパイラが使われています。OxcはパースやTypeScript/JSXの変換、モジュール解決、ミニファイなどを担当しており、これもVoidZeroが主導するプロジェクトです。
つまり、Vite 8.0の時点でビルドツール(Vite)・バンドラ(Rolldown)・コンパイラ(Oxc)が同じチームによって開発・保守される統合ツールチェーンが実現したことになります。パースからバンドル、ミニファイまで同一のアーキテクチャで動くので、「ここはesbuildの挙動、ここはRollupの挙動」と使い分ける必要がなくなりました。
Vite 8.0 の主な新機能一覧
機能 | 概要 | デフォルト |
|---|---|---|
Rolldownバンドラ統合 | esbuild + Rollupを置き換え、単一のRustベースバンドラに統合 | 有効 |
tsconfig pathsサポート |
| 無効(オプトイン) |
emitDecoratorMetadataサポート | TypeScriptのデコレータメタデータを外部プラグイン不要でサポート | 自動(tsconfig検出時) |
Vite Devtools | デバッグ・分析用の開発者ツールを統合 | 無効(オプトイン) |
Wasm SSRサポート |
| 有効 |
ブラウザコンソールフォワーディング | ブラウザのconsole.logをdevサーバーのターミナルに転送 | 無効(コーディングエージェント検出時に自動有効化) |
@vitejs/plugin-react v6 | React Refresh変換にOxcを使用、Babel依存を除去 | — |
Node.jsのサポート範囲
Vite 8.0ではNode.js 20.19以上または22.12以上が必要です。これはVite 7と同じ要件で、require(esm)をフラグなしでサポートするバージョンが対象となっています。
インストールサイズについて
Vite 8.0はVite 7と比較して約15MB大きくなっています。内訳は以下の通りです。
増加要因 | サイズ | 理由 |
|---|---|---|
lightningcss | 約10MB | CSS minificationの改善のため、オプショナルな依存から通常依存に変更 |
Rolldownバイナリ | 約5MB | esbuild + Rollupより大きいが、速度最適化を優先した結果 |
15MBの増加と聞くと気になりますが、これだけのビルド速度改善を考えれば十分許容範囲だと個人的には思います。
実際にアップグレードしてみた:手順と注意点
アップグレード方法は2つ
パス | 方法 | 推奨ケース |
|---|---|---|
直接アップグレード |
| 小〜中規模プロジェクト |
段階的マイグレーション | Vite 7のまま | 大規模・複雑なプロジェクト |
段階的マイグレーションは、Rolldown起因の問題とVite 8のその他の変更による問題を切り分けられるのがメリットです。大規模プロジェクトではこちらがおすすめです。
今回は社内のReact + TypeScriptプロジェクト(中規模、ページ数20ほど)で直接アップグレードを試しました。
実際の手順
# npmの場合
npm install vite@8
# pnpmの場合
pnpm add vite@8
# yarnの場合
yarn add vite@8React プロジェクトの場合、@vitejs/plugin-reactもv6にアップグレードすることを推奨します(v5でもVite 8で動作しますが、v6ではOxcによるReact Refresh変換に切り替わり、Babelが不要になります)。
npm install @vitejs/plugin-react@6アップグレード前のpackage.jsonはこんな感じでした。
{
"devDependencies": {
"vite": "^7.0.0",
"@vitejs/plugin-react": "^5.0.0",
"typescript": "^5.7.0"
}
}アップグレード後:
{
"devDependencies": {
"vite": "^8.0.0",
"@vitejs/plugin-react": "^6.0.0",
"typescript": "^5.7.0"
}
}vite.config.tsの変更
Vite 8.0には互換レイヤーが組み込まれており、既存のesbuildやrollupOptionsの設定を自動的にRolldown/Oxc相当のオプションに変換してくれます。そのため、多くのプロジェクトではvite.config.tsをまったく変更せずに動作します。
// vite.config.ts — 変更なしでVite 8でもそのまま動作
import { defineConfig } from 'vite'
import react from '@vitejs/plugin-react'
export default defineConfig({
plugins: [react()],
build: {
outDir: 'dist',
sourcemap: true,
},
})ただし、build.rollupOptionsやesbuildオプションを細かくカスタマイズしていた場合は、互換レイヤーでカバーしきれないケースがある可能性があります。詳細は公式マイグレーションガイドを必ず確認してください。
アップグレード時に確認しておきたいポイント
確認事項 | 詳細 |
|---|---|
Node.jsバージョン | 20.19以上または22.12以上が必須。古いバージョンを使っている場合は先にNode.jsのアップグレードが必要 |
Rollupプラグイン | Viteプラグインではなく、Rollupプラグインを直接使用している場合は互換性を確認。大半は動作するが、Rollup固有のフックに依存しているものは注意 |
esbuildオプション |
|
CSSの処理 | lightningcssがデフォルト依存になったことで、CSS minificationの挙動が微妙に変わる可能性がある |
個人的に嬉しかったのは、@vitejs/plugin-react v6でBabelが不要になった点です。node_modulesのサイズがだいぶスッキリしました。Babelの各種プリセット・プラグインが依存から消えるのは地味に大きい。
【ビルド速度を比較してみた】Vite 7 vs Vite 8

計測環境
項目 | 内容 |
|---|---|
マシン | MacBook Pro(M3 Pro, メモリ36GB) |
プロジェクト | React 19 + TypeScript 5.7、ページ数約20、コンポーネント数約120 |
計測方法 |
|
Vite 7 | v7.0.5(esbuild + Rollup) |
Vite 8 | v8.0.0(Rolldown) |
計測結果
# Vite 7でのビルド
$ time npx vite build
vite v7.0.5 building for production...
✓ 847 modules transformed.
✓ built in 4.82s
# Vite 8でのビルド
$ time npx vite build
vite v8.0.0 building for production...
✓ 847 modules transformed.
✓ built in 1.36s指標 | Vite 7 | Vite 8 | 改善率 |
|---|---|---|---|
本番ビルド時間(中央値) | 4.82秒 | 1.36秒 | 約71.8%短縮(約3.5倍高速) |
devサーバー起動 | 1.2秒 | 0.8秒 | 約33%短縮 |
HMR更新 | 体感差なし | 体感差なし | — |
正直、ここまで差が出るとは思っていませんでした。4.82秒が1.36秒って、約3.5倍の高速化です。中規模プロジェクトでこれなので、大規模プロジェクトではさらに差が開くと思われます。
公式ブログでも、実際の企業での導入事例が紹介されています。
企業 | 改善結果 |
|---|---|
Linear | 本番ビルド時間が46秒→6秒に短縮 |
Ramp | ビルド時間57%削減 |
Mercedes-Benz.io | ビルド時間最大38%削減 |
Beehiiv | ビルド時間64%削減 |
Linearの46秒→6秒は衝撃的ですね。大規模プロジェクトほどRolldownの恩恵を受けやすいことがよく分かります。
出力バンドルの比較
指標 | Vite 7 | Vite 8 |
|---|---|---|
出力ファイル数 | 23 | 22 |
合計バンドルサイズ(gzip前) | 1.42MB | 1.38MB |
合計バンドルサイズ(gzip後) | 412KB | 405KB |
バンドルサイズも若干小さくなりました。Oxcのセマンティック解析を活用した改善されたtree-shakingが効いているのかもしれません。速度も上がってサイズも減るなら文句なしです。
開発サーバーの体験
開発サーバーの使用感についても触れておきます。devサーバーの起動は体感で少し速くなった程度で、HMR(ホットモジュールリプレイスメント)の速度は体感上ほぼ変わりませんでした。もともとViteのHMRは十分高速なので、ここに差が出にくいのは当然かもしれません。
ただ、今後リリース予定のFull Bundle Mode(実験的機能)では、開発サーバーの起動が3倍高速化、フルリロードが40%高速化、ネットワークリクエストが10分の1になるという予備的な結果が報告されています。大規模プロジェクトではunbundledな開発アプローチがスケーリングの壁にぶつかることがあるので、この機能には期待しています。
tsconfig pathsを設定してみた

長年の小さな不満が解消
Vite 8.0の新機能の中で、地味だけど嬉しいのがビルトインのtsconfig pathsサポートです。
これまでTypeScriptのパスエイリアス(@/components/Buttonのような記法)をViteで使うには、vite-tsconfig-pathsプラグインを別途インストールするか、resolve.aliasにtsconfig.jsonと同じ設定を二重に書く必要がありました。「tsconfigに書いてあるのに、なんでViteにも書かなきゃいけないの?」というのは、多くの開発者が感じていた小さな不満だったと思います。
Vite 8.0では、vite.config.tsに1行追加するだけで済みます。
設定手順
// tsconfig.json
{
"compilerOptions": {
"baseUrl": ".",
"paths": {
"@/*": ["src/*"],
"@components/*": ["src/components/*"],
"@utils/*": ["src/utils/*"],
"@hooks/*": ["src/hooks/*"]
}
}
}// vite.config.ts
import { defineConfig } from 'vite'
import react from '@vitejs/plugin-react'
export default defineConfig({
plugins: [react()],
resolve: {
tsconfigPaths: true, // これだけ!
},
})これだけで、vite-tsconfig-pathsプラグインが不要になります。
# vite-tsconfig-pathsが不要に
npm uninstall vite-tsconfig-paths注意点
公式ドキュメントによると、この機能には「わずかなパフォーマンスコスト」があるとのことで、デフォルトでは無効になっています。私が試した範囲では体感できるほどの差はありませんでしたが、数千モジュール規模のプロジェクトでは影響が出る可能性があります。
また、tsconfig.jsonのreferences(プロジェクト参照)も自動的にスキャンされるため、モノレポ構成でも活用できます。これは嬉しいポイントですね。
試してみたかったが今後に持ち越し
Vite 8.0には今回試すところまでいかなかったものの、今後ぜひ深掘りしたい機能がいくつかあります。
Wasm SSR
WebAssemblyの.wasm?initインポートがサーバーサイドレンダリング(SSR)環境でも動作するようになりました。これまでSSR環境ではWasmの扱いが難しく、クライアントサイドのみでしかWasmを使えなかったプロジェクトも多かったと思います。
ただ、試すにはSSR環境の構築が必要で、今回はそこまで手が回りませんでした。Next.jsやRemixのようなSSRフレームワークと組み合わせた実装をいつか試してみたいと思っています。
Full Bundle Mode(開発サーバー高速化)
現在実験的機能として開発中のFull Bundle Modeは、開発サーバーでもフルバンドルを行うことで、大規模プロジェクトでのスケーリング問題を解決するアプローチです。予備的な結果では起動が3倍速、フルリロードが40%速、ネットワークリクエストが10分の1という数字が出ているとのことで、これは本格的に試してみたい。プロダクションへの導入ではなく、まずは開発環境での体験改善として評価したいと考えています。
Vite+ と Void
VoidZeroが発表したJavaScript統合ツールチェーン「Vite+」のオープンソース化と、ViteネイティブなWebアプリケーションプラットフォーム「Void」は、Viteエコシステムの次のフェーズを示すものです。VoidはCloudflare上に構築されたフルスタック実行環境とのことで、Vercelや他のEdgeプラットフォームとどう差別化するのか気になっています。こちらはまだベータ段階ということもあり、プロダクション利用は時期尚早ですが、今後のロードマップを追いかけていきたいと思います。
Vite Devtools
Vite Devtoolsはオプトインの開発者ツールで、パフォーマンス分析やデバッグ機能を提供します。有効化はvite.config.tsに設定を追加するだけですが、今回は時間の都合で試せませんでした。ビルド最適化の調査や遅いモジュールの特定に使えそうで、チームへの導入価値がありそうです。
まとめ
Vite 8.0を実際に試してみた率直な感想は「思ったより普通にアップグレードできた」です。互換レイヤーのおかげでvite.config.tsの変更は不要で、ビルドは約3.5倍速くなり、node_modulesも軽くなった。変更点のわりに移行コストが低いのは、Viteチームが互換性に相当力を入れた証拠だと思います。
特に効果を感じたのは以下の3点です。
改善点 | 体験 |
|---|---|
ビルド速度 | 4.82秒→1.36秒(約3.5倍)。CI/CDのコストにも直接影響する |
tsconfig paths統合 | プラグイン不要で1行追加のみ。地味だが開発体験が整理される |
@vitejs/plugin-react v6 | Babel依存がなくなり、node_modulesがスッキリ |
アップグレードを迷っている方には、まずステージング環境で試してみることをおすすめします。互換レイヤーがある分、大半のプロジェクトではそのまま動くはずです。それでも念のため公式マイグレーションガイドに目を通してから進めてください。
「Vite 2以来最大のアーキテクチャ変更」というのは誇張ではなく、Rolldownへの統合はViteが次のフェーズに進んだことを示しています。Full Bundle ModeやVoid等の今後の展開も楽しみで、引き続き追いかけていきます。















