MENU
  1. ホーム
  2. JS・フロントエンド
  3. 【Vite】Vite 8 移行ガイド2026 — Rolldown 統合で壊れる設定

【Vite】Vite 8 移行ガイド2026 — Rolldown 統合で壊れる設定

JS・フロントエンド
立方体と稲妻のモチーフでRolldown統合を表したVite 8のアイキャッチ画像

Vite 8移行で壊れる設定と実測ビルド速度を609モジュールの検証から整理します。Node.jsのバージョン要件、manualChunksからcodeSplittingへの書き換え、esbuild依存の設定まで確認できます。

目次

この記事が解決する悩み

  • Vite 8に上げたら設定が壊れて、どこを直せばいいか分からない
  • Rolldownに変わって何が起きるのか知りたい

対象読者: Viteでフロントエンドをビルドしている人
前提知識: Vite 7までのプロジェクトを持っていること

結論

先に結論です。Vite 8系へ上げるときに、まず見るべきポイントはこの3つだけです。

  • Node.js は 20.19 以上（または 22.12 以上）が必要
  • build.rollupOptions は build.rolldownOptions に置き換える
  • output.manualChunks のオブジェクト形式はエラーで落ちる。関数形式か output.codeSplitting に書き換える

書き換え後の vite.config.js はこうなります。

import { defineConfig } from 'vite'

export default defineConfig({
  build: {
    rolldownOptions: {
      output: {
        codeSplitting: {
          groups: [
            {
              name: 'vendor',
              test: /node_modules[\/]/,
            },
          ],
        },
      },
    },
  },
})

チャンク分割をしていないプロジェクトなら、設定ファイルは何も触らずに上げられます。互換レイヤーが旧オプションを自動変換してくれるためです。

Vite 8 の Rolldown 統合で何が変わったのか

Rolldown とは何か

Vite 8の一番大きな変更点は、バンドラーが2つから1つになったことです。

Vite 7までは、開発時にesbuild、本番ビルドにRollupという別々のツールが動いていました。モジュールの解決順や副作用の扱いが両者で微妙に違うので、「開発では動くのに本番ビルドで壊れる」という厄介なバグが生まれやすい構造でした。

Vite 8はRust製バンドラーのRolldownに一本化しました。開発も本番も同じエンジンを通るので、この種の差分が原理的に消えます。JavaScriptの変換とミニファイはOxcが担当し、ホットパスは全部Rustです。

時系列を整理しておきます。

  • 2026年3月12日 — Vite 8.0 リリース（Rolldownがデフォルトに）
  • 2026年5月7日 — Rolldown 1.0 リリース
  • 2026年6月23日 — Vite 8.1（実験的なバンドル配信モード、Chunk Import Map、WASM ESM連携）
  • 2026年7月30日 — Vite 8.2（トップレベルのinputオプション、PostCSS設定の型エクスポート）
  • 2026年9月10日 — Vite 8.3.0（Devtools連携、tsconfigオプション）

2026年9月時点のnpmのlatestは 8.3.0 です。移行先としては8系の最新をそのまま選んで問題ありません。

移行手順

1. Vite 8 に必要な Node.js バージョン（20.19 以上 / 22.12 以上）

Vite 8の engines は 20.19.0 以上、または 22.12.0 以上です。CIのNodeイメージが古いまま上げると、インストール時点で止まります。

node -v

# v22.12.0 以上、または v20.19.0 以上であることを確認

2. 先にrolldown-viteで検証する

いきなりVite 8へ上げず、Vite 7のままバンドラーだけRolldownに差し替える中間パッケージが用意されています。npmのlatestは 7.3.1 です。

大きなプロジェクトやプラグインを多用している場合は、こちらで先に地雷を踏んでおくほうが安全ですね。Rolldown固有の問題と、Vite 8本体の変更を切り分けられます。

{
  "devDependencies": {
    "vite": "npm:rolldown-vite@latest"
  }
}

3. Rolldown 向けに設定を書き換える

旧オプション名は互換レイヤーが吸収しますが、非推奨であることに変わりはありません。移行と同じタイミングで直しておくと、次のメジャーアップデートで慌てずに済みます。

  • build.rollupOptions → build.rolldownOptions
  • worker.rollupOptions → worker.rolldownOptions
  • optimizeDeps.esbuildOptions → optimizeDeps.rolldownOptions
  • esbuild → oxc

4. 本番ビルドを回してチャンクを確認する

ここが一番大事です。チャンクの切り方が変わると、初期表示で読むファイルも変わります。ビルドが通ったかどうかだけでは不十分で、dist/assets の中身と、動的importを使っている画面の動作まで見ておきましょう。

モジュールの移動は実行順に影響します。チャンクをいじったら、初期ルートと遅延読み込みしているルートを一通り開いて確認するのが確実です。

Rolldown 統合で実際に引っかかったポイント3つ

手元のVite 7プロジェクト（609モジュール）を8.3.0へ上げながら試した結果です。公式ドキュメントの記述と挙動が食い違う箇所もあったので、実際の出力を貼っておきます。

1. manualChunksのオブジェクト形式はビルドが落ちる

一番踏みやすいところですね。Rollupでよく使うオブジェクト形式を残していると、ビルドが途中で止まります。

// これは動かない
export default defineConfig({
  build: {
    rollupOptions: {
      output: {
        manualChunks: {
          vendor: ['dayjs'],
        },
      },
    },
  },
})

実行するとこんなエラーが出ます。

Warning: Invalid output options (1 issue found)
- For the "manualChunks". Invalid type: Expected Function but received Object.

error during build:
TypeError: manualChunks is not a function

「Expected Function but received Object」のとおり、Rolldownは関数しか受け付けません。書き換えは2通りあります。手軽なのは関数形式ですね。

export default defineConfig({
  build: {
    rolldownOptions: {
      output: {
        manualChunks(id) {
          if (id.includes('node_modules/dayjs')) {
            return 'vendor'
          }
        },
      },
    },
  },
})

ただし関数形式も非推奨です。Rolldownは codeSplitting という宣言的な書き方を用意していて、こちらが推奨になります。グループごとに名前とテストパターンを書くだけなので、見通しはこちらのほうが良いですね（最初に貼った設定がこれです）。

なお、旧名の advancedChunks もまだ動きます。ただし次の警告が出ます。

WARN  advancedChunks option is deprecated, please use codeSplitting instead.

ネット上では advancedChunks を紹介している記事も多いのですが、2026年9月時点の8.3.0では codeSplitting が正解です。古い記事をそのままコピーすると警告まみれになるので注意してください。

2. build.minify: ‘esbuild’ は依存ごと消えている

esbuildはVite本体の依存から外れ、オプショナル扱いになりました。ミニファイアを明示的にesbuildへ戻している設定はビルドが失敗します。

[plugin vite:esbuild-transpile]
Error: Failed to load `transformWithEsbuild`. It is deprecated and it now
requires esbuild to be installed separately. If you are a package author,
please migrate to `transformWithOxc` instead.

Caused by:
  Error: Cannot find package 'esbuild'

どうしてもesbuildに戻したいなら、esbuild をdevDependenciesへ自分で足す必要があります。プラグイン側で transformWithEsbuild を呼んでいる場合も同じです。マイグレーション先は transformWithOxc になります。

3. 非推奨オプションが無警告で通ることもある

ここは少し厄介でした。公式の移行ガイドには、build.rollupOptions や esbuild オプションに非推奨の警告が出るような書き方がされています。ところが手元の8.3.0では、どちらも警告なしで通りました。

設定は黙って変換され、ビルドも成功します。つまり、動いているから大丈夫とは言えない状態ですね。将来のメジャーアップデートで消える予定のオプションが、静かに残り続けることになります。CIに警告の検出を任せられないぶん、設定ファイル側は手で棚卸ししておくのが安全です。

開発中の配信も軽くできる（実験的機能）

Vite 8.1で入ったBundled Dev Modeも試してみました。experimental.bundledDev を有効にすると、開発中もモジュールをバンドルして配信します。以前はFull Bundle Modeと呼ばれていた機能ですね。

import { defineConfig } from 'vite'

export default defineConfig({
  experimental: {
    bundledDev: true,
  },
})

609モジュールのアプリで確認したところ、配信されるHTMLのエントリが変わりました。通常はブラウザが600本以上のモジュールを個別に取りに行きますが、有効にすると1本のバンドル（259KB）とHMR用クライアントだけになります。

<script type="module" src="/bundledDevClient.mjs"></script>
<script type="module" crossorigin src="/assets/index.js"></script>

リクエスト数が1回で済むので、モジュール数が多いプロジェクトほど効きます。まだ実験的扱いなので、まずは自分の手元だけ有効にして様子を見るのがいいですね。

実測：どのくらい速くなったか

合成アプリ（609モジュール、dayjsと動的importを含む）でVite 7.3.6と8.3.0を同じマシンで6回ずつビルドした結果です。Windows 11、Node.js 22.23.2での実測値になります。

項目 Vite 7.3.6 Vite 8.3.0
本番ビルド（609モジュール） 365 ms 59 ms
開発サーバー起動 236 ms 184 ms
出力サイズ（entry） 32.44 kB 31.26 kB

ビルドは約6倍、開発サーバー起動は1.3倍ほどでした。公式が掲げる10〜30倍という数字は数千モジュール規模での話で、この規模だと6倍くらいに落ち着きます。

それでも、起動時間よりビルドの伸びが大きいのははっきり分かります。CIで毎回ビルドを回しているチームほど、恩恵は大きいですね。

同じアプリのままVite 8でバンドル分割を有効にすると、vendor チャンクが7.18 kB、entryが2.35 kBまで分離されました。デプロイ後のキャッシュ効率を考えると、ここは設定しておきたいところです。

まとめ

移行でやることは、実はそこまで多くありません。

  • Node.jsのバージョンを上げる（20.19以上 / 22.12以上）
  • チャンク分割をしているなら manualChunks を codeSplitting へ書き換える
  • esbuild依存の設定やプラグインをOxcへ寄せる
  • ビルドが通るだけで終わらせず、チャンクと遅延読み込みの動作を確認する

一番の収穫は、ビルドが速くなったことよりも、開発と本番でバンドラーが同じになったことかもしれません。「開発では動くのに本番で壊れる」という、再現に時間を取られるタイプのバグが減ります。

警告が出ない非推奨オプションもあるので、動いているからと放置せず、この機会に設定ファイルを一度きれいにしておくのがおすすめです。

【広告】お名前.comならドメイン取得が格安。

検証環境

OS Windows 11 (build 10.0.26200)
CPU AMD Ryzen 9 PRO 8945HS w/ Radeon 780M Graphics
メモリ 28GB
言語/ツール Vite 8.3.0（npmで一時インストール） / Node.js 22.23.2
使用コマンド vite build（最小構成のプロジェクト）
測定日 2026-09-17

上記の環境で実際に実行して確認した結果です。環境が異なる場合は挙動が変わることがあります。

Vite 8.3.0 で実際にビルドし、Rolldown がバンドラとして入っていることを確認した結果
Vite 8.3.0 で実際にビルドし、Rolldown がバンドラとして入っていることを確認した結果

参考

本文の記述は以下の一次情報を確認して書いています。

あわせて読みたい

【広告】このサイトはConoHa WINGで運営しています。安定した高速サーバーで快適にブログを書けています。いつもありがとう！！

JS・フロントエンド
JavaScript migration Vite
よかったらシェアしてね！
  • URLをコピーしました！
  • URLをコピーしました！

コメント

コメントする

CAPTCHA


目次