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プロジェクトをVite+へ本格移行して検証したわけではないため、実際にどこまで設定を減らせるかはこれから試したいところです。
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
コメント