Vite 6とは?バージョン2以来の大型アップデート
Vite 6は2024年11月26日にリリースされた、Vite 2以降で最大規模のメジャーバージョンです。npmの週間ダウンロード数はVite 5リリース時の750万から1,700万へと約2.3倍に増え、OpenAI・Google・Apple・Microsoft・Shopify・Cloudflareなどグローバル企業のフロントエンド開発基盤として採用が拡大しています(出典: Vite公式ブログ)。
Vite 6最大の目玉はEnvironment APIの導入です。これまで暗黙的に扱われていた「クライアント」「SSR」という実行環境の区分を明示的に定義・拡張できるようになり、エッジランタイムを含む複数の実行環境を1つの開発サーバーで同時に扱えます。
Environment APIの仕組みと実用例
従来のViteが抱えていた制約
Vite 5まで、開発サーバーが扱える実行環境は「ブラウザ(クライアント)」と「Node.js(SSR)」の2つだけでした。Cloudflare WorkersやDeno Deployなどエッジランタイムへのデプロイが増える中、開発時と本番時の動作差異が課題になっていました。
たとえばCloudflare Workers向けのSSRアプリケーションを開発する場合、開発サーバーではNode.jsで動作するのに本番ではworkerdランタイムで動くため、Node.js固有のAPIに依存したコードがデプロイ後にエラーを起こすケースがありました。
Environment APIが解決すること
Environment APIを使うと、1つのVite開発サーバー上でブラウザ・Node.js・エッジランタイムなど複数の環境を同時に実行できます。各環境は独自のモジュールグラフと設定を持ち、対応するランタイムプロバイダーがコードの実行を担当します。
// vite.config.js - 複数環境の設定例
export default {
build: {
sourcemap: false,
},
environments: {
// クライアント環境(ブラウザ向け)
client: {
optimizeDeps: {
include: ['react', 'react-dom'],
},
},
// SSR環境(Node.js向け)
server: {},
// エッジ環境(Cloudflare Workers向け)
edge: {
resolve: {
noExternal: true,
},
},
},
}
トップレベルのbuildやresolveなどの設定はデフォルトでclient環境に適用され、serverやedge環境はクライアント設定を継承したうえで個別の上書きができます。
対象ユーザーとSPA開発者への影響
Environment APIの主なターゲットはフレームワーク開発者・プラグイン開発者・ランタイムプロバイダーです。通常のSPA/MPA開発者は設定を変更する必要がなく、Vite 5までと同じ使い方で動作します。
ただし、フレームワーク側がEnvironment APIを活用することで、ユーザーは意識せずにエッジランタイムでの開発体験が改善される恩恵を受けられます。
Environment APIのインターフェース
Environment APIが提供する設定の型定義は次のとおりです。
interface EnvironmentOptions {
define?: Record<string, any>
resolve?: EnvironmentResolveOptions
optimizeDeps: DepOptimizationOptions
consumer?: 'client' | 'server'
dev: DevOptions
build: BuildOptions
}
consumerフィールドで環境がクライアント側かサーバー側かを宣言し、それに応じたデフォルト設定が適用されます。
カスタム環境の作成
ランタイムプロバイダーが独自の環境を定義する場合、customEnvironment関数を利用できます。
import { customEnvironment } from 'vite-environment-provider'
export default {
build: {
outDir: '/dist/client',
},
environments: {
ssr: customEnvironment({
build: {
outDir: '/dist/ssr',
},
}),
},
}
この仕組みにより、Cloudflare Workers・Deno Deploy・Vercel Edgeなど各プラットフォーム固有のランタイム設定を環境として定義し、開発時から本番に近い条件でコードを検証できます。
Vite 5からの破壊的変更一覧
Vite 6は「ほとんどのプロジェクトが素早くアップグレードできる」ことを目指して設計されていますが、以下の破壊的変更に注意が必要です。
| 変更内容 | Vite 5の挙動 | Vite 6の挙動 | 対応方法 |
|---|---|---|---|
| Node.jsバージョン | 18/20/21対応 | 18/20/22+対応(21は削除) | Node.js 22へ更新 |
| resolve.conditions | 内部で自動付与 | 明示的な指定が必要 | defaultClientConditionsをインポートして結合 |
| JSON stringify | true設定時にnamedExportsが自動無効化 | namedExportsの設定値を尊重 | json.stringify: 'auto'(新デフォルト)をそのまま利用 |
| Sass API | レガシーAPIがデフォルト | モダンAPIがデフォルト | 互換性問題があればapi: 'legacy'を指定 |
| CSS出力ファイル名 | style.css固定 | package.jsonのnameフィールドから自動生成 | build.lib.cssFileName: 'style'で旧動作に戻す |
| postcss-load-config | v4 | v6 | TS設定ファイルの読み込みにtsxまたはjitiを利用 |
| HTML資産参照 | 限定的なHTML要素のみ | より多くのHTML要素に対応 | 除外したい要素にvite-ignore属性を付与 |
| build.cssMinify(SSR) | SSRビルドでは無効 | SSRビルドでも有効 | 必要に応じて明示的にfalseを設定 |
| terser最低バージョン | 5.4.0以上 | 5.16.0以上 | terserパッケージを更新 |
| commonjsOptions.strictRequires | 'auto' | true | バンドルサイズ増加の可能性がある点を認識 |
Vite 5からVite 6への移行手順
ステップ1: Node.jsバージョンの確認
node -v
# v18.x, v20.x, v22.x のいずれかが必要
Node.js 21を利用している場合はv22にアップグレードしてください。Node.js 18は2025年4月末にEOLとなるため、v20以上への更新を推奨します。
ステップ2: パッケージの更新
# npm
npm install vite@6
# pnpm
pnpm add vite@6
# yarn
yarn add vite@6
ステップ3: resolve.conditionsの確認
カスタムのresolve.conditionsを設定している場合、Vite 6が提供するデフォルト条件と結合する必要があります。
// vite.config.js
import { defaultClientConditions, defaultServerConditions } from 'vite'
export default {
resolve: {
conditions: ['custom', ...defaultClientConditions],
},
ssr: {
resolve: {
conditions: ['custom', ...defaultServerConditions],
},
},
}
カスタム条件を設定していないプロジェクトでは、この変更の影響を受けません。
ステップ4: Sass設定の確認
Vite 6ではSassのモダンAPIがデフォルトになりました。既存プロジェクトでsassパッケージのバージョンが古い場合や、レガシーAPI固有の記法を利用している場合は、一時的にレガシーモードへ切り替えることができます。
// vite.config.js
export default {
css: {
preprocessorOptions: {
sass: {
api: 'legacy', // Vite 7で廃止予定
},
},
},
}
長期的にはSassのモダンAPI記法への書き換えが推奨されます。
ステップ5: ライブラリモードのCSS出力確認
ライブラリモードでビルドしている場合、CSS出力ファイル名がpackage.jsonのnameフィールドから自動生成される仕様に変わりました。
// package.json
{
"name": "my-lib",
"exports": {
".": "./dist/my-lib.js",
"./style.css": "./dist/my-lib.css"
}
}
従来のstyle.css固定に戻したい場合は、build.lib.cssFileName: 'style'を設定してください。
ステップ6: ビルド検証
# 開発サーバーの動作確認
npx vite dev
# 本番ビルドの動作確認
npx vite build
# プレビューで出力確認
npx vite preview
Vite Runtime APIの廃止とModule Runner API
Vite 5.1で実験的に導入されていたVite Runtime APIは、Vite 6でModule Runner APIに置き換えられました。Module Runner APIはEnvironment APIの一部として設計されており、より柔軟な実行環境の管理が可能です。
Vite Runtime APIを利用していた場合は、公式のMigration Guideに従いModule Runner APIへの書き換えが必要です。ただし、Vite Runtime APIを直接利用していたのはフレームワーク開発者やプラグイン作者に限られるため、一般的なプロジェクトには影響しません。
Rolldown統合とVite 7以降のロードマップ
RolldownとOxcの役割
VoidZero社(Vite作者のEvan You氏が設立)が開発するRolldownは、Rustで書かれたJavaScriptバンドラーです。Vite 6時点のバンドラーはRollupですが、将来的にRolldownへ移行する計画が進行しています。
同じくRustベースのOxcプロジェクトは、パーサー・リンター・トランスフォーマーなどJavaScriptツールチェーン全体のRust化を目指しており、ViteConf 2024で進捗が発表されました(出典: Vite公式ブログ)。
Vite 6の段階でもRolldownを先行導入できます。rolldown-viteパッケージをドロップイン置換として利用する方法です。
// package.json
{
"devDependencies": {
"vite": "npm:rolldown-vite@latest"
}
}
早期導入企業の実測値は大幅な改善を示しています(出典: VoidZero)。
| プロジェクト | 改善前 | 改善後 | 備考 |
|---|---|---|---|
| GitLab | 2分30秒 | 40秒 | メモリ使用量も100分の1に削減 |
| Excalidraw | 22.9秒 | 1.4秒 | 約16倍の高速化 |
| PLAID Inc. | 80秒 | 5秒 | 約16倍の高速化 |
| Appwrite | 12分超 | 3分 | メモリ使用量も4分の1に削減 |
Rolldown統合は3段階のロードマップで進んでいます。
- 現在:
rolldown-viteとして別パッケージで早期採用者向けに提供 - 安定化: メインのViteパッケージにマージし、フルバンドル開発モードをオプション提供
- デフォルト化: フルバンドルモードが標準動作に
Vite 7での変更点
Vite 7は2025年6月24日にリリースされました(出典: Vite公式ブログ)。主な変更は次のとおりです。
- Environment APIは引き続き実験的: エコシステム全体のフィードバック期間が続いており、安定化は今後のバージョンに持ち越し。新たに
buildAppフックが追加 - Rolldown-viteの試験導入:
rolldown-viteパッケージによるドロップイン置換が可能に。将来的にデフォルトバンドラーとなる予定 - Node.js 18サポート廃止: Node.js 20.19以上または22.12以上が必要
- デフォルトブラウザターゲットの更新:
'modules'から'baseline-widely-available'へ変更(Chrome 87→107、Safari 14→16など) - ESM専用配布: ViteパッケージがESMのみで配布される形に移行
- SassレガシーAPIの完全廃止
Vite 8 Betaの動向
2025年12月3日にVite 8の最初のBeta版がリリースされました(出典: Vite公式ブログ)。Vite 8ではRolldownがデフォルトバンドラーとなり、これまでesbuild+Rollupの組み合わせで実現していたビルドパイプラインがRustネイティブのRolldownに一本化されます。Rolldownはesbuildと同等の速度を持ちつつRollupの10〜30倍高速とされており、本番ビルドの大幅な高速化が期待されています。
Vite 6を選ぶ判断基準
すぐにアップグレードすべきケース
- 新規プロジェクトの立ち上げ:
npm create vite@latestで自動的にVite 6以降が使われます - Cloudflare Workers・Deno Deployなどエッジランタイムを利用するSSRアプリ: Environment APIによる開発体験の改善が得られます
- Vite 5のセキュリティパッチが終了するタイミング: Vite 5のサポート終了に備えた移行
現時点でVite 5に留まってもよいケース
- SassレガシーAPIに強く依存しているプロジェクト: モダンAPI対応の工数が大きい場合は段階的に対応
- SPA開発のみでSSRやエッジランタイムを使わないプロジェクト: 破壊的変更の恩恵が限定的
ただし、Node.js 18のEOLが2025年4月末に迫っているため、遅くとも2025年前半にはVite 6以降へのアップグレードを計画するのが安全です。
よくある質問
Vite 6のEnvironment APIは必ず使わないといけませんか?
使う必要はありません。Environment APIはフレームワーク開発者向けの機能であり、SPA/MPA開発者は従来の設定ファイルのまま動作します。フレームワーク側がEnvironment APIを内部的に活用することで、ユーザーは意識せずに恩恵を受けられる設計です。
Vite 6のリリースサイクルはどうなっていますか?
Viteには一定のリリースサイクルがありません。パッチリリースは約1週間ごと、マイナーリリースは約2ヶ月ごとのベータ段階を経て、メジャーリリースはNode.jsのEOLスケジュールに合わせて約1年ごとにリリースされます(出典: Vite公式ドキュメント)。
Vite 6でHMR(Hot Module Replacement)は高速化されましたか?
Vite 6単体でのHMR速度の劇的な改善は公式には発表されていません。HMRの大幅な高速化はRolldownの本格統合(Vite 7〜8世代)で見込まれます。ただし、Environment APIにより複数環境でのHMR管理が整理されたため、SSRを含む複雑な構成でのHMR安定性は向上しています。
まとめ
Vite 6の核心はEnvironment APIの導入です。ブラウザ・Node.js・エッジランタイムを1つの開発サーバーで統一的に扱えるようになったことで、開発環境と本番環境のギャップが縮小しました。
破壊的変更は限定的で、resolve.conditionsやSass APIのデフォルト変更が中心です。SPA開発のみのプロジェクトではほぼ変更不要でアップグレードできます。
Rolldown・Oxcによるツールチェーンのネイティブ化はVite 7〜8で本格化しており、Vite 6はその橋渡し的なリリースでもあります。今後のパフォーマンス飛躍に備え、早めの移行をおすすめします。
新規プロジェクトの開始は以下のコマンドから可能です。
npm create vite@latest
