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,
      },
    },
  },
}

トップレベルのbuildresolveなどの設定はデフォルトでclient環境に適用され、serveredge環境はクライアント設定を継承したうえで個別の上書きができます。

対象ユーザーと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 stringifytrue設定時にnamedExportsが自動無効化namedExportsの設定値を尊重json.stringify: 'auto'(新デフォルト)をそのまま利用
Sass APIレガシーAPIがデフォルトモダンAPIがデフォルト互換性問題があればapi: 'legacy'を指定
CSS出力ファイル名style.css固定package.jsonのnameフィールドから自動生成build.lib.cssFileName: 'style'で旧動作に戻す
postcss-load-configv4v6TS設定ファイルの読み込みに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)。

プロジェクト改善前改善後備考
GitLab2分30秒40秒メモリ使用量も100分の1に削減
Excalidraw22.9秒1.4秒約16倍の高速化
PLAID Inc.80秒5秒約16倍の高速化
Appwrite12分超3分メモリ使用量も4分の1に削減

Rolldown統合は3段階のロードマップで進んでいます。

  1. 現在: rolldown-viteとして別パッケージで早期採用者向けに提供
  2. 安定化: メインのViteパッケージにマージし、フルバンドル開発モードをオプション提供
  3. デフォルト化: フルバンドルモードが標準動作に

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