Vite+ 1.0が2026年9月28日に正式リリースされました。
開発が進められている事は以前より知っていて楽しみにしていましたが、ついにメジャーリリースされたので調べてみました。
最初に概要を見たときの率直な感想は、「もう、とりあえずVite+を最初に検討すればいいのでは」。
筆者は、普段Astro + Bun + Viteを中心に、なるべく軽く、依存や設定ファイルを増やしすぎない構成を好んで使っていますが、実際のプロジェクトではlint、format、test、type check、CIと周辺ツールが少しずつ増えていきます。
Vite+は、そうして分かれていったツール群をもう一度ひとつの開発体験として扱おうとしています。
Vite周辺の開発ツールをひとつの入口へまとめる
Vite+ 1.0の公式発表では、Vite+はフレームワークや特定のパッケージマネージャーを置き換えるものではなく、Viteを含む開発ツールチェーンをひとつの入口へまとめる製品として説明されています。
中心にあるのは、これまで別々に導入していたツール群です。
- Vite / Rolldownによる開発サーバーとビルド
- Vitestによるテスト
- Oxlintによるlint
- Oxfmtによるformat
- tsdownによるライブラリビルド
- Vite Taskによるタスク実行とキャッシュ
これらを単一のvite-plusパッケージとvpコマンドから扱います。
たとえば静的チェックなら、
vp check
でformat、lint、type checkをまとめて実行できます。
Vite+のvp checkドキュメントによると、formatはOxfmt、lintはOxlint、型チェックはTypeScript Go toolchainのtsgoを利用し、tsgolintは型情報を使ったlintルールを提供します。
これまでなら、
ESLint
Prettier
TypeScript
Vitest
Vite
各ツールの設定ファイル
package.jsonのscripts
と少しずつ組み上げていたところを、Vite+側でひとまとまりとして扱えるわけです。
個々のツールを選ぶ自由は好きですが、プロジェクトを作るたびに同じ組み合わせを選び直すとなると、コードを書く前にlintやformatの構成を考えるのが煩わしくなりがちです。
速さ以上に「選ばなくていい」が気になる
Vite+の土台にはRust製の高速なツールが多く使われています。
公式ではOxlintやOxfmtの速度も大きくアピールされています。個人的に気になったのは、その速さ以上に、開発環境の選択肢を減らせることでした。
最近のJavaScript開発は、昔よりツール自体はかなり良くなっています。
Viteは速い。Vitestも使いやすい。OxlintやOxfmtのようなRust製ツールも増えました。
そのぶん、
「lintは何を使う？」
「formatterは？」
「テストは？」
「タスクランナーは？」
「Nodeのバージョン管理は？」
「パッケージマネージャーは？」
と、最初に決めることも増えています。
Vite+は、相性の確認されたツール群をひとつの入口から扱えるようにして、この初期判断を減らします。
この考え方はかなり好みです。
Bunとは役割を分けて共存できる
最初に気になったのが、個人的に愛用しているBunとの相性でした。
Bunもランタイム、パッケージマネージャー、テスト、bundlerなどをまとめて持っているので、Vite+とは方向性が少し重なります。
少なくともパッケージマネージャーとしてBunを使う場合、Vite+へ移行するためにBunをやめる必要はありません。
Vite+のPackage Managementドキュメントでは、pnpm、npm、Yarnに加えてBunも正式に扱われています。bun.lock、bun.lockb、bunfig.tomlもパッケージマネージャー判定の対象です。
つまり、
Bun
└─ package manager
Vite+
├─ Vite / Rolldown
├─ Oxlint / Oxfmt
├─ Vitest
└─ Vite Task
という使い分けもできます。
筆者がBunを使っている大きな理由は、installが速く、CLIが軽く、日常の操作がシンプルだからです。
その意味では、Bunをパッケージマネージャーとして残しながら、lintやformatなどをVite+へ寄せる構成はかなり自然に見えます。
Vite+のグローバルCLIにはNode.js自体を管理する機能もありますが、プロジェクトローカルのvite-plusパッケージは既存のNode.jsランタイムとパッケージマネージャー上でも利用できます。
Vite+は、開発環境全体を寄せる使い方にも、周辺ツールだけをまとめる使い方にも対応しています。
Bunとは役割を分けられそうでした。では、Viteを内部で使うAstroはどうでしょうか。
AstroではdevとbuildをAstro側に残す
AstroはもともとViteをかなり深く使っています。現在のAstro 7もVite 8とRolldownを採用しており、Astroの設定からViteの設定を渡す仕組みも用意されています。
一見するとそのままVite+へ置き換えられそうに見えますが、現時点ではAstroのdevやbuildはAstro自身に実行させるほうが無難です。
Vite+のvp runドキュメントには分かりやすい例があります。
{
"scripts": {
"dev": "astro dev"
}
}
というプロジェクトなら、
vp run dev
でastro devを実行できます。
vp dev
の場合は、Vite+組み込みのVite dev serverが起動します。
Astroで使うなら、
Astro
└─ dev / build
Vite+
├─ check
├─ lint
├─ format
├─ test
└─ task runner
くらいの分担から始めるのが無理がなさそうです。
Astroには固有のビルドパイプラインやルーティング、アダプターがあります。Viteを内部利用していても、AstroそのものをVite+へ置き換えられるわけではありません。
その後、実際にAstro + Bunで動いているhappas.jpへVite+ 1.0を持ち込み、GitHub Actions上で試してみました。
環境はAstro 7.3系、Bun 1.4.2です。Vite+側ではbun.lockを自動検出し、vp install --frozen-lockfileからそのままbun installが実行されました。少なくともパッケージ管理については、Bunとの共存はかなり素直です。
その後、CIでもsetup-vpを入口にして、vp install、vp lint、vp run check / test / buildへ寄せました。setup-vp v1.21.1の公式ドキュメントでは、CI上でpackage manager管理が既定で有効になり、Bunを含む各package managerをVite+側で管理できると説明されています。実際にpackageManager: [email protected]を持つ環境では、別途setup-bunを置かなくてもBun 1.4.2が用意され、vp installからbun installが実行されました。
Astro CLIについては、package scriptをbun run --bun astro ...にしてBun runtimeを明示しています。つまり、Vite+を司令塔にしながら、package managerとAstro CLIのruntimeはBunのまま維持する構成です。
一方、vp run check、vp run test、vp run buildを実行すると、未移行のプロジェクトでは「This project does not use vite-plus」という警告が出ます。実際の処理も、bun run --bun astro check、bun test、bun run --bun astro buildといった既存のpackage.json scriptをVite Task経由で呼び出す形でした。
つまり、vp runを使えたこと自体は既存プロジェクトとの共存性を確認できた一方で、これだけでツールチェーンがVite+へ置き換わったわけではありません。既存scriptをそのまま包む段階と、OxlintやOxfmtなどへ実際に寄せる段階は分けて考えたほうがよさそうです。
ネイティブ側も少し試しました。vp lintはJS / TS系60ファイルを27msで処理し、9件のwarningを検出しました。速度は確かにかなり軽快です。ただしvendorコードまで対象にすると不要なwarningも混ざるため、実運用では除外設定が必要になります。
vp fmt --checkでは61ファイル中34ファイルにformat差分が出て、「No config found, using defaults」と表示されました。Oxfmt自体はすぐ動きますが、既存プロジェクトへ入れる場合は、現在の書式とVite+側のデフォルトをどう合わせるかという移行作業は普通に残ります。
今回の検証ではAstroファイル自体はネイティブlint / formatの対象から外しました。Astro固有部分は従来どおりastro checkへ任せ、まずJS / TS周辺からVite+へ寄せるのが現実的に見えます。
実際に触ってみると、最初に考えていた、
Astro
└─ dev / build
Vite+
├─ check
├─ lint
├─ format
├─ test
└─ task runner
という分け方は少し雑でした。
既存のAstroプロジェクトでは、まずは、
Astro / Bun
├─ dev / build
├─ Astro固有のcheck
└─ 既存test
Vite+
├─ vp runによる既存scriptの実行
├─ Oxlint
└─ Oxfmt
くらいから始め、置き換えられる部分だけ段階的に寄せるほうが自然です。
その後、project-localのvite-plusとvite.config.tsまで導入し、初回format差分も整理したうえで、CIのvp lintとvp fmt --checkはvp checkへまとめられました。最終的には、format・lint・TypeScriptのtype checkをVite+へ任せ、Astro固有の診断はastro check、既存testはBunのまま残す形に落ち着いています。
Vite+
└─ vp check
├─ format
├─ lint
└─ TypeScript check
Astro / project
└─ Astro固有のcheck
Bun
└─ test
Vite Taskのキャッシュも試しました。通常のpackage.json scriptが自動でキャッシュされるわけではないため明示的に有効化し、同一CI job内で再実行するとbun testはcache hitしました。ただし削減は約144msで、重いastro checkはGitHub Actions側の環境変数変化もあり安定したhitになりませんでした。CI runをまたいで再利用するには別途キャッシュの永続化も必要になるため、このプロジェクトでは設定の複雑さに対する効果が小さいと判断して採用していません。
実際に使ってみると、Vite+は「使える機能を全部有効にする」より、vp checkのように既存構成を素直に簡略化できるところから寄せるほうが扱いやすく感じました。
AstroとVoidZeroがCloudflareの近くに集まった
Astroとの関係を調べていて、もうひとつ気になったのがCloudflareです。
Astroを開発するThe Astro Technology Companyは、2026年1月にCloudflareへの参加を発表しました。
さらにVite、Vitest、Rolldown、Oxc、Vite+を開発するVoidZeroも、2026年6月にCloudflareへ加わっています。
現在は、
Cloudflare
├─ Astroチーム
└─ VoidZero
├─ Vite
├─ Vitest
├─ Rolldown
├─ Oxc
└─ Vite+
という関係になっています。
最初は「Vite+もCloudflare製だったっけ」と思ったのですが、正確にはVoidZeroがVite+を開発し、そのVoidZeroが後からCloudflareへ加わった形です。
ここまで近いところに集まっていると、AstroとVite+の親和性も今後さらに高くなってほしいな、と期待してしまいます。
Cloudflare傘下だからAstroがVite+を採用すると決まったわけではなく、両プロジェクトともオープンソースかつベンダーニュートラルを維持すると説明しています。そのうえで、AstroとVite+の開発チームが同じCloudflareの近くに集まったことで、両者の境界が今後どう整理されるのかは以前より気になるところです。
普段AstroやCloudflare Workersを使う立場からすると、開発体制の継続性については以前より安心して見られるようになりました。
新規プロジェクトではかなり有力な候補
既存プロジェクトを今すぐ全部移行するほど急ぐ必要は感じませんが、新しく作るプロジェクトならVite+はかなり魅力的に見えます。
筆者のようにAstro + Bunを使っている場合でも、
Framework Astro
Package Manager Bun
Toolchain Vite+（段階導入）
Deploy Cloudflare
という組み合わせは十分ありそうです。
何より、プロジェクトを作るたびに「今回のリンター何にしよう」「formatterどうしよう」と考えなくてよくなるなら、それだけで十分うれしい。
モダンで高速なベストプラクティスを毎回自分で組み立て直さずに済む、その安心感をVite+には期待しています。
参考：Astro 7.0
