Vite+とは？vpコマンドの使い方と1.0の中身・既存Vite案件の移行手順を実装目線で解説

Vite+は、VoidZeroがVite・Vitest・Rolldown・tsdown・Oxlint・Oxfmtと独自のタスクランナーをvpという1つのコマンドに束ねた統合ツールチェーンです。2026年9月28日に1.0が公開され、npm registryを10月5日に確認した時点でvite-plusのlatestは1.0.0、ライセンスはMITでした。Node.jsのランタイムとパッケージマネージャーの管理まで抱え込む点が、Vite単体との分かれ目になります。この記事では、Vite+が何を同梱しているか、インストールからvite.config.tsへの設定集約、既存プロジェクトをvp migrateで移す手順、CIへの組み込み、そして受託開発で採用してよい条件までを、コマンドと設定例つきで扱います。

まとめ：Vite+を新規案件で採用する条件と既存案件で待つ線引き

結論から置きます。Viteでビルドする新規案件で、CIのNode.jsを22.18以上か24.11以上に揃えられるなら、Vite+で始めて問題ありません。lint・フォーマット・型チェック・テスト・ビルドの設定がvite.config.tsの1枚に寄り、ESLintとPrettierとlint-stagedをそれぞれ別に保守する作業が消えます。

待つべきなのは次の場面です。Node.js 20系のCIを当面上げられない構成。Oxlintが対応していないESLintプラグインに品質ゲートを預けている構成。Vitestなど個々のツールの版を、Vite+の公開周期と切り離して上げたい構成。この3つに当たるなら、まずVite 8とVitest 4.1以上へ上げる下準備だけを進め、Vite+への移行は後段に回してください。

Vite+とは何か｜vpコマンドに束ねたツール群と1.0で固定された版の中身

まず、何が入っていて何が入っていないのかを版番号の単位で押さえます。Vite+を「Viteの次の版」と誤解したまま導入すると、設定の置き場所を取り違えます。

Vite本体ではなくCLIの統合層としてのVite+が担う役割の範囲

Vite+はViteを置き換えるものではありません。開発サーバーとビルドはVite 8とRolldownが担い、Vite+はその上にvpというCLIの層を被せて、テスト・lint・フォーマット・ライブラリ用ビルド・タスク実行を同じ入口から呼べるようにしたものです。公式のGetting Startedは、日常の作業をvp create・vp dev・vp check・vp test・vp buildの流れで説明しています。

Vite単体の仕組みや開発サーバーの考え方は、Viteとは？Reactの環境構築手順とVite 8の変更点・create-react-appからの移行にまとめてあります。本記事はその上に載る統合層だけを扱います。

同梱される7つのツールとnpm registryで実測した版番号の一覧

npm registryでvite-plus 1.0.0の依存を2026年10月5日に確認すると、各ツールは範囲指定ではなく版を固定して同梱されていました。

同じ日に単体パッケージを見ると、viteのlatestは8.3.2、vitestのlatestは5.0.3でした。Vite+経由のVitestは5.0.1に留まっています。個々のツールの修正版を待たずに取り込みたい案件では、この固定が足かせになる点を覚えておいてください。手元でどの版が入っているかはvp toolchainで確認できます。lint単体の性格はOxlintとは？読み方・使い方とESLint・Biomeとの違いを解説に分けてあります。

1.0で確定したライセンスとNode.js要件・ベータからの変更点

VoidZeroの1.0告知は、Vite+をMITライセンスの無償OSSと明記し、週200万ダウンロード目前で2,600超の公開リポジトリが依存していると述べています。2026年3月のアルファ、7月のベータを経ての安定版です。開発元のVoidZeroは同年6月にCloudflareへの合流を発表しています。

ベータからの差分として告知が挙げるのは、GitLab CI/CD向けのsetup-vp、vp migrateのtsup移行対応、HomebrewとDockerイメージの提供、vp toolchainとvp hooksの追加です。Node.jsの要件はnpmのenginesで^22.18.0 || ^24.11.0 || >=26.0.0。Node 20系はここで対象外になります。

Vite+の検証環境を作る｜インストールからvp createでの新規作成まで

ここから手を動かします。グローバルCLIを入れて、新規プロジェクトを1つ作り、5つのコマンドを一巡させるところまでです。

macOS・LinuxとWindowsで分かれるグローバルCLIの導入コマンド

公式の手順では、OSごとにインストーラを取得して実行します。macOSとLinuxはシェルスクリプト、WindowsはPowerShellです。

# macOS / Linux
curl -fsSL https://vite.plus | bash

# Windows（PowerShell）
irm https://vite.plus/ps1 | iex

# 入ったツールの版を一覧で確認
vp toolchain

1.0からはHomebrewとDockerイメージでも配布されています。社内の端末管理でcurlからのスクリプト実行を禁じている場合は、そちらの経路を選んでください。グローバルCLIを入れたくないCIでは、後述するsetup-vpか、プロジェクトの開発依存にvite-plusを入れてnpx vpで呼ぶ方法が取れます。

vp createから本番ビルドまで6つのコマンドを一巡させる手順

新規プロジェクトはvp createで雛形を作り、あとは依存の導入から本番ビルドまでを順に流します。

vp create        # 雛形を対話形式で作成
vp install       # 依存を導入（パッケージマネージャーは自動判定）
vp dev           # 開発サーバーを起動
vp check         # フォーマット・lint・型チェックを一括実行
vp test          # Vitestでテストを実行
vp build         # Rolldownで本番ビルド

ライブラリを作る場合は、最後のvp buildの代わりにvp packを使います。こちらはtsdownを呼び出し、型定義の出力まで担当するコマンドです。vp testの中身はVitestそのものなので、テストの書き方はVitestとは？Viteネイティブなテスト基盤の仕組みと採用判断を実装目線で解説の内容がそのまま通用します。

Node.jsとパッケージマネージャーを自動で選ぶ解決順序の仕組み

Vite+はnvmやVoltaの役割も兼ねます。公式のEnvironmentガイドによると、Node.jsの版は最も近いディレクトリの宣言が勝ち、同じディレクトリ内では.node-version、package.jsonのdevEngines.runtime、engines.node、.nvmrcの順に見ます。

vp env pin 24.11.0    # このプロジェクトのNode.jsを固定（.node-versionを書く）
vp env current        # いま解決されている環境を表示
vp env install        # 解決された版を導入

パッケージマネージャーは、明示指定、環境変数VP_PACKAGE_MANAGER、packageManagerフィールド、devEngines.packageManager、ロックファイルの順に決まります。pnpm・npm・Yarn・Bunのいずれにも対応しているため、既存のロックファイルがあればそれに従う仕組みです。Voltaのメンテナンス終了に伴う移行先を探している場合は、Volta（ヴォルタ）とは？Node.jsバージョン管理の使い方とメンテ終了・mise移行と並べて比べると判断しやすくなります。

vite.config.tsに設定を集約する｜lint・fmt・test・runの書き分け

Vite+の利点の大半は、ツールごとに散っていた設定ファイルを1枚へ寄せられる点にあります。ブロックの名前と既定の挙動を押さえておけば、設定の置き場所で迷いません。

1枚のdefineConfigにlintとテストとタスクを並べる設定例

インポート元はviteではなくvite-plusです。lint・fmt・test・run・staged・packが同じオブジェクトに並びます。

import { defineConfig } from 'vite-plus';

export default defineConfig({
  lint: {
    ignorePatterns: ['dist/**'],
    options: {
      typeAware: true,  // 型情報が要るルールを有効化
      typeCheck: true,  // lint中に型チェックも実行
    },
  },
  test: {
    environment: 'jsdom',
  },
  run: {
    tasks: {
      build: {
        command: 'vp build',
        dependsOn: ['lint'],
        cache: { env: ['NODE_ENV'] },
      },
    },
  },
  staged: {
    '*.{js,ts,tsx,vue,svelte}': 'vp check --fix',
  },
});

typeAwareとtypeCheckは、公式のCheckガイドで両方を有効にする構成が推奨されています。後者を有効にすると、vp checkがTypeScriptのGo実装とtsgolintを使って型チェックまで1回で済ませます。tsc --noEmitを別ジョブで回していた構成なら、そのジョブを畳むことが可能です。

vp checkの一括実行とフォーマットだけ外すときのオプション

vp checkはOxfmtによるフォーマット、Oxlintによるlint、型チェックを1つのコマンドで流します。公式の説明では、別々に実行する場合よりも高速です。手元で整形まで直したいときは--fix、警告を黙らせてエラーだけ見たいときは--quietを付けます。

vp check --fix       # 整形と自動修正まで実施
vp check --no-fmt    # フォーマットを飛ばしてlintと型だけ
vp check --no-lint   # lintルールを飛ばす

フォーマットを別の仕組みに任せているリポジトリでは、vite.config.tsにcheck: { fmt: false }と書けばvp checkからだけ外せます。vp fmt単体の挙動は変わりません。ESLintとPrettierの代替としてBiomeも候補に挙がる場合は、Biome v2とは？最新2.5系の導入・biome.json設定とESLint/Prettier移行で比較の軸を確認してください。

vp runのタスク定義とpackage.jsonスクリプトのキャッシュ差

vp runはpackage.jsonのスクリプトとvite.config.tsのタスクの両方を実行します。公式のRunガイドによると、差が出るのはキャッシュの既定値です。package.jsonのスクリプトは既定でキャッシュされず、vite.config.tsに書いたタスクは既定でキャッシュが効きます。スクリプト側も--cacheを付ければキャッシュ対象になります。

vp run build                      # 依存タスクを順に解決して実行
vp run -r build                   # 全ワークスペースで実行
vp run --filter "@my/*" build     # 名前やglobで対象を絞る

もう1点、vp devは組み込みコマンドで、vp run devはpackage.jsonのdevスクリプトです。同名でも組み込み側は上書きされません。モノレポでTurborepoを既に入れている場合、vp runと役割が重なります。両方を残すと依存順序とキャッシュの定義が二重になるため、どちらか一方に寄せてください。比較の材料はTurborepoとは：2.11系のturbo.json設定・キャッシュ共有・CI高速化を実装で解説にあります。

既存のVite案件をvp migrateで移行する手順と互換設定の外し方

新規より手間がかかるのは既存プロジェクトです。公式の移行手順は前提条件が厳しめなので、順番を守るのが近道になります。

Vite 8とVitest 4.1へ先に上げておく前提条件と移行コマンド

公式の移行ガイドは、既存プロジェクトではまずVite 8以上とVitest 4.1以上へ上げてからvp migrateを実行するよう求めています。あわせて、元のロックファイルと依存はそのまま残すよう注意書きがあります。移行前に依存を一斉更新すると、Vitest v4互換の設定を引き継げなくなるためです。

# グローバルCLIがある場合
vp migrate --no-interactive

# グローバルCLIを入れずに実行する場合（版はpackageで固定する）
npx --package vite-plus vp migrate --no-interactive

# 移行後の確認
vp install
vp check
vp test
vp build    # ライブラリなら vp pack

グローバルCLIを使わない実行では、公式は--packageに1.0.0のように版を明示する書き方を示しています。CIや複数人での移行作業では、版を固定して結果を揃えてください。

vp migrateが書き換えるESLint・Prettier設定とimport文の範囲

vp migrateは依存の更新、importの書き換え、ツールごとの設定のvite.config.tsへの統合、package.jsonスクリプトの置き換え、移行後の整形までを1回で行います。コミットフックやエディタ・エージェント向けの設定ファイルの生成は任意です。

差分を読むときに目を通すべき箇所は2つあります。1つはESLintとPrettierの設定がOxlintとOxfmtの設定に変換された結果で、手で足していたカスタムルールが落ちていないかを確かめます。もう1つはvite buildがvp buildに、eslintがvp lintに置き換わったスクリプト群です。CIのジョブ定義が古いスクリプト名を直接呼んでいると、そこで止まります。

Vitest 5の互換設定を1つずつ外して挙動を確かめる進め方

Vite+ 1.0はVitest 5.0.1を同梱しているため、Vitest 4のプロジェクトを移すとメジャーを1つ跨ぎます。公式のVitest 5アップグレードガイドによると、vp migrateは旧来の挙動を保つ互換設定を自動で書き込みます。

公式の指示は、これらを一度に1つずつ外し、そのたびにvp checkとvp testで挙動を確かめることです。まとめて外すと、どの設定が原因で落ちたのか切り分けられません。確認が済んだら生成されたコメントも消し、残す設定には残す理由を書き添えます。

CIとコミットフックにVite+を組み込むときの設定例と注意点

ローカルで動いたら、CIとコミット前のチェックへ広げます。Vite+はどちらにも専用の仕組みを持っています。

setup-vpアクションでGitHub Actionsのジョブを組む設定例

公式のCIガイドは、GitHub Actionsでvoidzero-dev/setup-vpを使う構成を示しています。Node.jsの版と依存キャッシュをこのアクションに任せ、あとはvpのコマンドを並べるだけです。

steps:
  - uses: actions/checkout@v5
  - uses: voidzero-dev/setup-vp@<setup-vp-version>
    with:
      node-version: '24'
      cache: true
  - run: vp install
  - run: vp check
  - run: vp test
  - run: vp build

<setup-vp-version>には、setup-vpのリリースページにある正確な版を入れます。公式はv1タグを使わないよう注意しており、このタグは更新が届かなくなっている状態です。依存のキャッシュはアクションが持ちますが、vp runのタスク結果をジョブ間で使い回したい場合は、別途GitHub Actionsのキャッシュ設定を足す必要があります。GitLab CI/CD向けのsetup-vpも1.0で加わりました。

vp stagedとvp hooksでlint-stagedとhuskyを置き換える設定

コミット前のチェックは、vite.config.tsのstagedブロックに対象のglobと実行コマンドを書くだけで動きます。vp stagedはlint-staged 17を同梱しており、Gitフックの管理はvp hooksが受け持ちます。

vp config            # フックとエージェント設定を書き込む
vp hooks status      # フックの有効・無効を確認
vp hooks disable     # この端末だけ無効化して再導入も防ぐ

要件はNode.js 22.22.1以上か24.11.0以上、Git 2.32.0以上です。CIのように特定の環境でだけフックを止めたいときは、環境変数VP_GIT_HOOKS=0を設定します。huskyとlint-stagedを別々に保守していたリポジトリなら、開発依存を2つ減らせる計算です。

ツールチェーン統一を受託案件の開発体制に組み込むときの進め方

Vite+を入れる判断は、ツールを1つ増やす話ではなく、開発体制の取り決めを変える話です。どの版のNode.jsで、どのコマンドを、どの順でCIが叩くのか。その約束がvite.config.tsと.node-versionに書き下されるため、案件に途中参加したメンバーの環境差による事故が減ります。逆に言えば、取り決めを決めないまま入れると、ローカルとCIで別の版が動く状態が残ります。

DevOps・CI/CD導入支援では、ツールチェーンの選定からCIのジョブ設計、既存リポジトリの段階的な移行計画までを含めて相談を受けています。ESLintやPrettier、huskyの設定が案件ごとにばらばらで保守が重くなっている場合は、まず各リポジトリのNode.jsの版と品質チェックの構成を棚卸しするところから着手してください。

受託開発でVite+を採用してよい条件と見送るべき構成の切り分け

最後に、案件ごとの判断を条件として言い切ります。1.0になったとはいえ、どの構成にも入れてよい段階ではありません。

新規のVite案件で迷わず採用してよい3つの条件と得られる効果

新規案件では、次の3つを満たせばVite+で始めます。第一に、フロントエンドのビルドをViteで行うこと。第二に、開発端末とCIのNode.jsを22.18以上か24.11以上に揃えられること。第三に、lintのルールをOxlintの標準ルールの範囲で組めること。

得られる効果は、設定ファイルの数とCIのジョブ数が目に見えて減ることです。ESLint・Prettier・lint-staged・husky・nvmそれぞれの設定と依存がvite.config.tsと.node-versionに集まり、CIはvp check・vp test・vp buildの3段で済みます。パッケージマネージャーをpnpmで固めるかどうかは、pnpmとは？共有ストアの仕組みとv12のRust実装・モノレポ運用を解説を参考に先に決めておくと、packageManagerフィールドの値で迷いません。

既存案件でVite+への移行を見送るべき構成と待つ間の事前準備

次の構成では、いまはVite+へ移しません。webpackやNext.jsのTurbopackでビルドしている構成は、Vite+の前提から外れます。セキュリティやアクセシビリティの品質ゲートをESLintのプラグインに預けていて、Oxlint側に同等のルールが無い構成も同様です。lintを置き換えた時点で、守っていたはずのルールが検査されなくなる恐れがあるためです。

Vitestやlintの版を、Vite+の公開を待たずに個別に上げたい案件も見送りの側です。1.0.0時点で同梱のVitestは5.0.1、単体のlatestは5.0.3でした。この差を許容できないなら、単体ツールの組み合わせのほうが運用に合います。待つ間にできる準備は、Vite 8とVitest 4.1以上への更新、Node.jsの22.18以上への引き上げ、ESLintルールのうちOxlintに無いものの洗い出しの3つです。ここまで済ませておけば、移行はvp migrate1回と互換設定の整理で終わります。Rolldown以前のバンドラ構成から移る場合の位置づけはRollupとは？npmでの導入と使い方・rollup.config.mjsの書き方とVite 8以降の位置づけで確認できます。

よくある質問

Vite+の導入前によく挙がる疑問を、1.0.0時点の公式情報に沿って整理しました。

Vite+は有料ですか？ライセンスはどうなっていますか？

無償で使えます。1.0の公式告知は、Vite+をMITライセンスのオープンソースと明記しており、npm registryのvite-plus 1.0.0のライセンス欄もMITです。ソースはGitHubのvoidzero-dev/vite-plusリポジトリで公開されています。商用案件に組み込む場合も、MITの表示義務を守れば追加の契約は要りません。

Vite+とVite 8は何が違いますか？

Vite 8は開発サーバーとビルドを担うツールで、Vite+はその上に載る統合CLIです。Vite+の中ではVite 8とRolldownがビルドを受け持ち、テスト・lint・フォーマット・タスク実行・Node.jsの版管理をvpコマンドが束ねます。Viteだけ使いたいなら、従来どおりVite単体で問題ありません。

Node.js 20系の環境でもVite+は動きますか？

1.0.0の要件から外れます。npm registryのenginesは^22.18.0 || ^24.11.0 || >=26.0.0で、同梱のVitest 5も同じ範囲を求めています。Node 20系のCIを使っている場合は、先にランタイムを22.18以上へ上げてください。vp env pinで.node-versionを書けば、開発端末側の版も揃えられます。

ESLintとPrettierの設定はそのまま使えますか？

そのままでは使いません。vp migrateがESLintとPrettierの設定をOxlintとOxfmtの設定へ変換し、vite.config.tsへ統合します。変換後の差分で、手で追加していたカスタムルールやプラグイン由来のルールが残っているかを必ず確かめてください。Oxlintに同等のルールが無いものは、変換後に残らない前提で点検するのが安全な進め方です。

モノレポでTurborepoと併用できますか？

併用自体は可能ですが、役割が重なります。vp runはワークスペースを認識した依存順序の解決とタスクのキャッシュを持ち、-rや--filterで対象パッケージを選べます。Turborepoと両方に同じタスクを定義すると、依存関係とキャッシュの定義を二重に保守することになるため、新規ならどちらか一方に寄せる設計を選んでください。

関連記事

• Viteとは？Reactの環境構築手順とVite 8の変更点・create-react-appからの移行
• Vitestとは？Viteネイティブなテスト基盤の仕組みと採用判断を実装目線で解説
• Oxlintとは？読み方・使い方とESLint・Biomeとの違いを解説
• Biome v2とは？最新2.5系の導入・biome.json設定とESLint/Prettier移行
• Turborepoとは：2.11系のturbo.json設定・キャッシュ共有・CI高速化を実装で解説