Vite 6の変更点 - Environment APIとVite 5からの移行

8分 で読める | 2025.01.21

公式ドキュメント
JS開発ツールWeb開発

Vite 6は2024年11月26日にreleaseされました。最大のarchitecture変更はEnvironment APIですが、Vite 6時点では実験的APIで、主な対象はframework・plugin・toolの開発者です。一般的なSPAではVite 5と同じ設定を使えるようbackward compatibilityが重視されました。

この記事の位置づけ

記事情報: 2025年1月21日初出。Vite 6 announcementと当時のmigration guideを2026年7月25日に再確認しています。

Vite 6は現在のlatest majorではありません。新規projectでは使用frameworkが推奨するstarterと現在のVite stable版を使ってください。この記事は、Vite 5から6へ移行する既存projectや、6で入ったarchitecture変更を調べるためのversion別資料です。

Vite 6の主要点は次のとおりです。

  • 実験的Environment APIを導入
  • experimental Vite Runtime APIをModule Runner APIへ変更
  • resolve.conditionsの既定値と上書き方法を変更
  • large JSONの扱いを調整
  • Sass modern APIを既定化
  • library modeのCSS file名を変更
  • PostCSS config読み込み、glob、SSRなど一部挙動を変更

「Rust製RolldownがVite 6のproduction bundlerへ全面的に置き換わった」というreleaseではありません。Vite 6のannouncementはRolldown統合へ向けたecosystemの進展を紹介していますが、移行時はVite 6の実際の変更と将来計画を分けます。

Environment API

従来のViteはclientとSSRという暗黙の実行環境を中心にしていました。Environment APIは、browser、Node.js server、edge runtimeなど複数environmentを明示し、それぞれにmodule graph、configuration、runtime connectionを持たせるための基盤です。

import { defineConfig } from "vite";

export default defineConfig({
  build: {
    sourcemap: false,
  },
  environments: {
    server: {},
    edge: {
      resolve: {
        noExternal: true,
      },
    },
  },
});

Vite 6の公式documentはEnvironment APIをexperimentalと明記しています。Vite 6の間はAPIを保つ方針でしたが、Vite 7でbreaking changeを伴う安定化が予定されていました。application利用者が独自environmentを作るより、framework・adapterが提供する設定を使うのが基本です。

単一clientのSPAでは新しいconceptを設定へ書く必要はありません。Environment APIを使わないことはVite 6の機能を利用できていないという意味ではありません。

Module Runner API

Vite 5.1のexperimental Vite Runtime APIは、Vite 6でModule Runner APIへ変わりました。experimental APIを直接使っていたtoolは移行が必要ですが、通常のapplication codeへの影響は限定的です。

pluginやframeworkを開発している場合は、古いserver.ssrLoadModule周辺の内部APIへ依存していないか確認します。公開されていないinternal APIはEnvironment APIのrefactorで削除されたものがあります。

Node.js support

Vite 6 release時点ではNode.js 18、20、22以降をsupportし、Node.js 21を外しました。ただしNode.js 18は2025年4月にEOLを迎えています。

現在Vite 6を保守する場合も、EOL済みNode.jsを選ぶ理由にはなりません。Vite、framework、pluginの対応範囲を確認し、support中のNode.js LTSへ上げます。

node --version
npm ls vite

local、CI、Docker、deployment先のversionをそろえます。

resolve.conditionsの変更

Vite 6ではclientとserverのdefault conditionsがexportされ、custom conditionを指定するときは既定値を自分で含める必要があります。

import {
  defaultClientConditions,
  defaultServerConditions,
  defineConfig,
} from "vite";

export default defineConfig({
  resolve: {
    conditions: ["custom", ...defaultClientConditions],
  },
  ssr: {
    resolve: {
      conditions: ["custom", ...defaultServerConditions],
    },
  },
});

resolve.conditionsを設定していないprojectには影響しません。custom exports conditionを使うmonorepoやSSR projectだけを重点的に確認します。

JSONの扱い

json.stringifyの既定値は"auto"になり、大きなJSONだけをstringifyする動作になりました。またjson.stringify: trueでもjson.namedExportsの設定が尊重されます。

export default defineConfig({
  json: {
    stringify: true,
    namedExports: false,
  },
});

大きなJSONをimportするapplicationではbuild outputとruntime動作を確認します。named exportへ依存するcodeがある場合は、明示設定で意図を残します。

SassとPostCSS config

Vite 6ではSassのmodern APIが既定になりました。custom importerやfunctionなどでlegacy APIの挙動へ依存している場合はSass公式migration資料を確認します。

一時的には次の設定でlegacy APIを選べましたが、Vite 7で削除予定と案内されていました。

export default defineConfig({
  css: {
    preprocessorOptions: {
      scss: {
        api: "legacy",
      },
    },
  },
});

長期的な解決はmodern APIへの移行です。

またpostcss-load-configの更新により、TypeScriptのPostCSS configを読むにはtsxまたはjiti、YAML configにはyamlが必要になりました。config fileの拡張子を確認してください。

Library modeのCSS file名

Vite 5ではlibrary modeのCSS outputがstyle.cssでした。Vite 6ではpackage.jsonのnameなどに基づくfile名へ変わり、build.lib.cssFileNameで明示できます。

export default defineConfig({
  build: {
    lib: {
      entry: "src/index.ts",
      name: "MyLibrary",
      fileName: "my-library",
      cssFileName: "style",
    },
  },
});

packageのexports、READMEのimport例、CDN URL、test fixtureがdist/style.cssを前提にしていないか確認します。

影響が限定的な変更

利用機能によっては次も確認します。

  • HTML asset referenceの対応elementが拡大
  • 対象elementへvite-ignoreを付けて処理を除外可能
  • SSR buildでもCSS minifyが既定で有効
  • WebSocket upgrade時にもproxy bypassが呼ばれ、resがundefinedの場合がある
  • terserのminimum versionが5.16.0
  • CommonJS pluginのstrictRequiresがtrue
  • glob implementation変更でrange・incremental braceが非対応
  • SSRでCSS default importの意図しないsupportを削除

すべてを設定へ転記する必要はありません。repositoryを検索し、使用している項目だけtestします。

rg "resolve\\.conditions|json\\.stringify|cssFileName|postcss|import\\.meta\\.glob" .

Vite 5からの移行手順

  1. Node.js、framework、official pluginの対応versionを確認する
  2. Vite 5最新でtestとbuildを通す
  3. lockfileを保ったままVite 6へ上げる
  4. development server、HMR、production buildを確認する
  5. custom plugin、SSR、library modeを重点的にtestする
  6. build outputのfile名とpackage exportsを比較する
  7. stagingでbase path、asset URL、proxyを確認する
npm install --save-dev vite@6
npm run build
npm run test

framework projectではViteだけを単独更新せず、frameworkのmigration guideとpeer dependencyに従います。SvelteKit、Nuxt、AstroなどはViteの低level APIをframework側で吸収するためです。

まとめ

Vite 6は、一般的なSPAの移行を小さく保ちながら、複数runtimeを扱うframework向けにEnvironment APIの実験を始めたreleaseです。Environment APIはVite 6時点でexperimentalであり、application開発者が必ず直接使う機能ではありません。

移行では派手な性能比較より、custom conditions、Sass、PostCSS config、library CSS、SSR、pluginの互換性を確認してください。最新majorへ直接移る場合も、Vite 6で入った変更を経由差分として理解するためにこのmigration guideを利用できます。

参考リソース

おすすめ記事

← 一覧に戻る
PR
PR
PR
PR