本文へ移動
技術を、自社の仕事に。
判断と実行を助けるメディア

記事を検索

Vite+ 1.0正式版、移行前に確かめるNode要件とvp migrate

目次 · 6項目

保守しているWebサイトのリポジトリを開くと、vite.config.js、eslint.config.js、.prettierrc、Vitestの設定がそれぞれ別の版で並んでいる。どれか1つを上げるたびに、ほかの道具との組み合わせを確かめ直す手間がかかる。こうした道具を1つに束ねるVoidZeroの統合ツールチェーン「Vite+」は、ベータ版の段階でベータ公開時の記事として紹介しました。

その Vite+ が1.0になりました。1.0なら移してよいのか、ライセンスや料金は変わったのか、手元やCIのNode.jsで動くのか。リリースノートとnpmの公開記録を照合し、このPCで新規作成と移行を試した結果をまとめます。

1.0で何が「安定版」になったのか

voidzero-dev/vite-plus リポジトリの v1.0.0 タグが指すコミットは、2026年9月28日(UTC 02:20)付の「release: v1.0.0: Vite+ 1.0 is stable」です。npmの vite-plus@1.0.0 は同じ日の05:37(UTC)に公開され、10月4日時点の latest も1.0.0です。

リリースノートによると、1.0.0は9月26日のRC(v1.0.0-rc.1)を「no code changes」(コードの変更なし)で安定版にしたものです。中身の変化は2つのRCにあります。9月22日のrc.0でテストランナーがVitest 5に上がり、CLIのNode.jsの要件が変わりました。rc.1ではタスクのキャッシュ設定が cache の下へ移りました。どちらもリリースノートでは互換性を壊す変更(Breaking Changes)の扱いです。

1.0.0に同梱されている道具の版は次のとおりです(リリースノートの表と、vp --version の出力で確認)。

役割道具1.0.0の版
開発サーバー・ビルドVite / Rolldown8.3.1 / 1.2.11
テストVitest5.0.1
リント(型を見るルールを含む)Oxlint / oxlint-tsgolint1.85.0 / 7.0.2003
整形Oxfmt0.70.0
ライブラリのビルドtsdown0.23.0

一方、1.0以降の互換性の方針を定めた文書は、v1.0.0時点のリポジトリ(README・docs・rfcs)には見当たりませんでした。今後も更新のたびにリリースノートの「Breaking Changes」を確かめる前提で考えておくのが安全です。

ライセンスと料金は変わっていない

リポジトリの LICENSE はMITで、npmの vite-plus と @voidzero-dev/vite-plus-core の1.0.0も license は MIT です。ライセンスの変更履歴を見ると、2025年10月27日にBusiness Source License 1.1(本番利用に制限がある方式)が置かれ、2026年2月27日の「chore: Switch to MIT License.」でMITに切り替わっています。商用利用の条件が変わったのはこの2月の時点で、1.0で新たに変わったものはありません。 料金について、9月28日付のVoidZeroの1.0の告知は、Vite+を「無料で、MITライセンスのオープンソース」と説明しています。リポジトリの文書にも有料プランや利用料の記載はありませんでした。なお告知は、リモートキャッシュなどの機能は今後の版で予定しているとして、1.0の時点で機能がそろいきったわけではないとも書いています。

Node.jsの要件:20系と22.18未満は外れる

移行できるかどうかに直結するのは、Node.jsの要件です。npmに記録された engines は次のように変わりました。

  • 0.3.3(9月18日):^20.19.0 || ^22.18.0 || >=24.11.0
  • 1.0.0-rc.0以降と1.0.0:^22.18.0 || ^24.11.0 || >=26.0.0

Node.js 20系は対象外になり、22系は22.18.0以上が必要です。>=24.11.0 が ^24.11.0 に変わったため、奇数版の25系も外れています。コミット前のフックで使う vp staged はさらに厳しく、Node.js ^22.22.1 || ^24.11.0 || >=26.0.0 とGit 2.32.0以上が必要です(rc.0のリリースノート)。Node.js自体のサポート期間はNode.js 24の保守期入りと26のLTS化の記事で整理しています。

CI・開発者の端末・ビルドサーバーのどこかに20系や古い22系が残っていれば、そこで止まります。.nvmrc、package.json、GitHub Actions、ホスティングのビルド設定にある版を先に洗い出しておきます。

このPCで新規作成と移行を試した

ここからは実機検証です。2026年10月4日、Linux(Node.js v22.22.0、npm 10.9.4、git 2.43.0)の隔離した作業ディレクトリで、vite-plus@1.0.0 をプロジェクトに入れて試しました。グローバルのインストーラーは、vite.plus に接続できず使っていません。

npm 10.9.4では、そのままでは入らなかった

空のプロジェクトで npm install -D vite-plus@1.0.0 を実行すると、npm 10.9.4は npm error Cannot read properties of null (reading 'edgesOut') で止まりました。公式の移行ガイドにある npx --package=vite-plus@1.0.0 vp ... も同じエラーです。Vite 8を入れた別のプロジェクトにVitest 4.1を追加したときも同じエラーが出たため、Vite+固有の問題ではなく、このnpmの版で依存関係を解決するときの問題とみられます。

READMEの手動導入の手順どおり package.json に overrides(vite の置き換えと vitest の版の固定)を書くと、npm 10.9.4でも入りました。npm 11.21.0の npm exec --package=vite-plus@1.0.0 -- vp --version は、overridesなしで vp v1.0.0 を表示しました。CIのイメージのnpmの版も先に確かめておきます。

新規作成:check・test・buildは通った

vp create vite:application --no-interactive --package-manager npm でアプリのひな型を作り、簡単なテストを1つ足して実行しました。vp check・vp lint・vp test・vp build はいずれも終了コード0でした。

$ npx vp check
pass: All 8 files are correctly formatted (516ms, 4 threads)
pass: Found no warnings, lint errors, or type errors in 4 files (602ms, 4 threads)
$ npx vp test
 Test Files  1 passed (1)
      Tests  1 passed (1)

生成された vite.config.ts では型を見るリントと型チェック(typeAware / typeCheck)が有効で、vp check 1回で整形・リント・型チェックを確かめる作りです。なお、v22.22.0は vp staged の要件(22.22.1以上)を満たしませんが、この環境では vp staged もエラーなく動きました。動いたことを根拠に要件外の版で運用するのは避けます。

既存構成の移行:ESLintとPrettierの設定が消える

次に、Vite 8・ESLint 9(@eslint/js の推奨ルール)・Prettier 3(semi: false、singleQuote: true)を使う小さなプロジェクトを作り、gitに記録してから vp migrate --no-interactive を実行しました。

ESLint 9とPrettier 3を使う検証用のViteプロジェクトでvp migrateを実行した前後の比較。eslint.config.jsと.prettierrcが削除され、vite.config.jsのlintとfmtに設定が移り、scriptsがvpコマンドに置き換わった。ESLintの2ルールは対応外として飛ばされ、移行直後のvp checkはindex.htmlの整形で失敗し、vp check --fixの後に通った

変更点は図のとおりです。

  • eslint.config.js と .prettierrc は削除され、内容は vite.config.js の lint と fmt に移った(semi: false などの指定も残った)
  • scripts は vite → vp dev、eslint . → vp lint .、prettier --write . → vp fmt . に置き換わった
  • devDependenciesは vite-plus と vite の置き換え(@voidzero-dev/vite-plus-core)だけになった
  • ESLintの no-dupe-args と no-octal は「Superseded by strict mode.」として飛ばされた

移行直後の vp check は index.html の整形の違反で終了コード1になり、vp check --fix の後に通りました。vp build も成功しています。移行ガイドも「Most projects will require further manual adjustments after running vp migrate.」と書いています。

もう1つ、Vitestのテストを含むのにVitestが入っていない状態で実行すると、BLOCK [source-version] Cannot determine the original Vitest version. で止まり、「No project files were changed.」と表示されました。メッセージは元のロックファイルを入れてから再実行するよう求めており、移行ガイドも元の依存関係とロックファイルを残して始めるよう書いています。

検証は各1回、数ファイルの検証用プロジェクトです。Astroなどを使う実案件のサイト、ESLintのプラグインが多い構成、pnpmやモノレポでは試していません。

移すか待つか(編集部の提案)

ここまでの事実を踏まえた、編集部の整理です。

いまの状況編集部の提案
CIやビルド環境のどこかにNode.js 20系・22.18未満が残る先にNode.jsを上げる。Vite+の移行はその後
Vite 8より前、またはVitest 4.1より前Vite・Vitestを先に上げ、テストが通る状態で記録してから
ESLintのプラグインやルールを多用移行で飛ばされたルールを一覧にし、代わりがない分を受け入れられるか決める
すでにVite+ 0.3を使っている公式の「Upgrade from Vite+ 0.3 to 1.0」の手順で、依存を更新する前に vp migrate
納品後に触る頻度が低い小規模サイト急いで移す理由は少ない。次の大きな改修に合わせて検討

移行するときの手順と落とし穴

  1. ブランチを切り、ロックファイルを残したまま始める。 元の版が分からないと、Vitestを含むプロジェクトでは移行が止まります。
  2. vp migrate の出力を保存する。 飛ばされたルール、BLOCK や REVIEW の項目はここにしか出ません。
  3. vp check --fix の差分を確認してからコミットする。 PrettierとOxfmtで整形の結果が異なるファイルが差分に出ます(検証では index.html)。
  4. vp install・vp check・vp test・vp build を通す。 移行ガイドが挙げる確認の順序です。
  5. CIは voidzero-dev/setup-vp を正確な版かコミットSHAで指定する。 READMEは「Do not use the v1 tag.」(v1 タグは更新されない)と注意しています。
  6. エディターの設定を見直す。 rc.0で、Vite+が用意していた oxlint・oxfmt のコマンドのラッパーがなくなり、エディターからは vp lint --lsp・vp fmt --lsp を使う形になりました。tsconfig.json の baseUrl は型チェックの経路が対応しておらず、移行時の自動修正が失敗すると型チェックは有効になりません(troubleshootingの記載)。

2026年10月4日に、voidzero-dev/vite-plus リポジトリ(v1.0.0 = commit fc287d7)のREADME・LICENSE・docs/guide、v1.0.0と2つのRCのリリースノート(リリースのコミットに記録された本文)、npmレジストリの公開記録を直接開いて照合しました。インストール・新規作成・移行は上記の検証環境で1回ずつ確認したものです。10月5日に、voidzero.dev の1.0の告知(9月28日付)と、npmレジストリの公開日時・engines を改めて確認しました。実案件のサイトの移行、pnpm・Yarn・Bun、Windows・macOS、グローバルの vp CLIは確認していません。

Viteを使ったサイトやアプリの開発環境の見直し、CIを含む移行の進め方は、グリームハブへご相談ください。

Sources

この記事を共有XFacebook
鈴木 翔

技術の可能性に魅了され、学生時代からプログラミングとデジタルアートの分野に深い関心を持つ

この記事のテーマを、自社の次の一歩へ

自社での進め方を、具体的に。

つくりたい仕組み、既存システム、運用の条件を整理し、実現に向けた次の一歩を考えます。

  • 実現したい仕組み
  • 既存環境との接続
  • 運用の条件
開発・運用の構想を相談する

構想段階からご相談いただけます。この記事の情報を相談フォームに引き継ぎます。

最新記事をメールで受け取る