- プロジェクトごとに別々に組み立てていたWeb開発ツールの負担を減らすため、Vite+ はランタイム、パッケージマネージャー、ビルド・テスト・検査ツールを1つのエントリーポイントにまとめた
vp dev, vp check, vp test, vp build, vp pack, vp run が Vite 8, Vitest, Rolldown, tsdown, Oxlint, Oxfmt と連携し、一貫したコマンド体系を提供する- アルファ以降、12以上のバージョンと500以上のPRを経て、キャッシュ、マイグレーション、組織テンプレート、企業ネットワーク対応、クロスプラットフォーム安定性が改善された
- 公開リポジトリベースで 1,300以上 が
vite-plus に依存しており、Dify、critical、BlockNote、vinext、îles、Inkline、npmx などのプロジェクトがすでに利用中
- まだ1.0前段階のため、リモートキャッシュ、GitLab CI/CD対応、フレームワーク・プラグイン互換性、マイグレーション、配布チャネルと診断の改善が残っている
Vite+ が提供する統合ツールチェーン
- Vite+ はWeb開発のための統合ツールチェーンとしてベータ公開された
- 1つのエントリーポイントでランタイムとパッケージマネージャーを管理し、複数のフロントエンドツールを検証済みスタックとしてまとめて提供する
- MITライセンスの完全なオープンソースで、特定のフレームワークに依存しない
- CLI、ライブラリ、Webアプリなど、さまざまなWebプロジェクトで利用できる
- 新規プロジェクトは
vp create、既存プロジェクトは vp migrate で始める
同じコマンドで開発・検査・ビルドを実行
- Vite+ は、リポジトリごとに異なるツールの組み合わせやコマンドを覚える代わりに、同じコマンド体系を使えるよう設計されている
- 主なコマンドは次のとおり
vp dev: Vite 8ベースでホットモジュールリプレースメントを含む開発サーバーを起動するvp check: Oxfmt によるフォーマット、Oxlint によるlint、型チェックをまとめて実行するvp test: Vitest ベースの単体テストを実行するvp build: Vite 8ベースで本番ビルドを実行するvp pack: tsdown ベースでライブラリをバンドルし、ベストプラクティスを含むvp run: 内蔵のモノレポ認識タスクランナーで npm スクリプトやタスクを実行し、インテリジェントキャッシュを利用する
- チームやコードベースが大きくなるほど、次の利点が大きくなる
- ツールのバージョンが揃う
- 設定共有がしやすくなる
- 新規コントリビューターのセットアップ工程が減る
- CI がローカル開発と同じコマンドを実行する
- ツールチェーンを毎回自分で組み立てたくない開発者や、プロジェクト全体で一貫した設定を求めるチーム向けに設計されている
- Vite+ は Viteエコシステム を置き換えるものではない
- Vite プラグインは引き続き Vite プラグインのまま
- プロジェクトは内部的に好みのパッケージマネージャーを引き続き利用できる
- Vite+ は、これらの要素が1つのツールチェーンのように動作するための統合レイヤーを提供する
アルファ以降、ベータまでの変化
- Vite+ アルファ以降、実プロジェクトでのテストを経て 12以上のバージョン がリリースされ、500以上のPR がマージされた
- 主な改善点は次のとおり
- より賢いキャッシュ:
vp run は 自動データトラッキング と Vite が報告するメタデータを組み合わせ、入力・出力・環境変数を手動で列挙しなくてもビルドキャッシュが正しく機能する
- マイグレーション改善:
vp migrate がさまざまなアプリ設定を処理し、エージェント向けのマイグレーションプロンプトも提供する
- エンタープライズ機能: 組織テンプレート でチーム間の設定を標準化し、プロキシおよびカスタムCA対応HTTP により企業プロキシやファイアウォールの背後でも
vp を実行できる
- クロスプラットフォーム: 主要OSやシェルでより確実に動作するよう
vp が強化された
- 洗練と改善:
vite-plus に 180以上の修正と改善が反映された
- 詳細な変更履歴は Vite+ リリース記録 で確認できる
ともに進化した基盤ツール群
- Vite+ の開発と並行して、基盤ツールも継続的に改善されてきた
- アルファ以降の主な変化は次のとおり
実際の導入事例
vite-plus に依存する公開リポジトリは 1,300以上 あり、非公開プロジェクトやグローバルCLIインストールは含まれない- さまざまな種類のプロジェクトで Vite+ が使われている
- Dify: LLM アプリ構築向けのオープンソースプラットフォーム
- critical: Addy Osmani によるフレームワーク非依存の critical-path CSS ツール
- BlockNote: React 向けのブロックベース Notion スタイルのリッチテキストエディタ
- vinext: Vite ベースの Next.js 互換ドロップインフレームワーク
- zerobyte: TanStack と React で作られたセルフホストユーザー向けバックアップ自動化
- îles: Vue 向けの部分ハイドレーション islands サイトジェネレーター
- agentsview: Svelte で作られた、コーディングエージェント向けローカルファーストのセッション検索・分析ツール
- Inkline: Vue, React, Svelte, Angular, Solid, Qwik, Astro をサポートするUIコンポーネントライブラリ
- npmx: Nuxt ベースのオープンソース npm レジストリブラウザー
- npmx の Daniel Roe は、Vite+ によって開発体験を高速に保てるだけでなく、CI やレビュー工程も高速化されると述べている
1.0 までに残る課題
- Vite+ は安定しているが、まだ完成段階ではなく、統合ツールチェーンに必要な機能要件を満たすなら導入を勧めている
- 1.0 までに注力する項目は次のとおり
vp run である Vite Task 向け リモートキャッシュ の実装- GitLab CI/CD 向け
setup-vp の導入
- Vite フレームワークおよびプラグイン全般の互換性改善
- より多くのマイグレーション対象のサポート
- 公式 Homebrew formula など配布チャネルの追加
- ドキュメントと診断のさらなる明確化
- 1.0 リリース前に残る互換性ギャップを減らすため、コミュニティからのフィードバックを優先している
インストールとマイグレーション
- グローバル
vp コマンドは macOS/Linux では次のコマンドでインストールする
curl -fsSL https://vite.plus | bash
- Windows では次の PowerShell コマンドを使う
irm https://vite.plus/ps1 | iex
vp create
- 既存の Vite プロジェクトで Vite+ を試すには次のコマンドを使う
vp migrate
vp migrate は変更計画を表示するが、複雑なプロジェクトでは手動の追加入力が必要になる場合がある- 本番プロジェクトに Vite+ を導入する前に マイグレーションガイド を読む必要がある
- 特に既存プロジェクトをマイグレーションする開発者、フレームワークやプラグインの作者、大規模リポジトリを維持するチームからのフィードバックを求めている
- 関連チャネル
1件のコメント
Hacker Newsの意見
Vite は本当に気に入っているけれど、ほかのツールが何なのかはまったく分からない。
ちょっと頭を下げて仕事している間に、フロントエンドのツール体系が急に進化していて、退屈だけどちゃんと動くスタックへ向かう流れがあるのか気になっている。
oxlint は eslint の代替で、設定ファイル形式と互換性があり、JavaScript で書かれていないので非常に速い。biome も使ったが、oxlint のほうがルールが多く eslint 互換性も高かった。
oxfmt は prettier の代替で、JavaScript で書かれていないのでより高速。rolldown は rollup の代替で互換性がありつつ、はるかに速い。新規プロジェクトではすでにこうしたツールを主に使っている。
以前は別々のオープンソースプロジェクトのツールを、それぞれ異なる設定や更新サイクルで使わなければならなかったが、今ではひとつのシンプルなツールチェーンとして扱える。
Vite+ は事実上「退屈だけどちゃんと動く」スタックで、性能も高く、設定も少なくて済む。
eslint → oxlint、prettier → oxfmt のように Rust で書き直して高速化し、webpack → Vite はすでに十分広く使われているので受け入れる流れ。
rolldown → tsdown は TypeScript 対応を追加し、jest → vitest は Vite と相性がいい。
この10年で定着した慣習を取り込みつつ、TypeScript 対応、Rust ベースの性能、相互運用性をひとつにまとめる形だ。
Deno も使っているが、どんな点が便利なのか気になる。
Vite、Vitest、Oxlint、Oxfmt が好きで、新しいプロジェクトの大半でまずこちらを見る。
彼らが十分な資金を確保して、少なくとも今後10年は開発を続けられるといいと思う。
古いプロジェクトを開くと Gulp、Grunt、webpack、そのほかバラバラのツールが入り混じっているより、はるかにまし。そういうプロジェクトのひとつも新しいスタックへ移行した。
焦点は、Cloudflare が彼らにVite と Vite+ の機能を作り続けさせるかどうかだ。Cloudflare だけでなく、あらゆるクラウドプラットフォームに利益をもたらす機能だから。
https://blog.cloudflare.com/voidzero-joins-cloudflare/
とくにサーバーサイドレンダリングを含むフルスタックだとなおさらで、フロントエンドだけを見て TypeScript を外せばかなり簡単になる。
より複雑なケースで Vite+ が役立つかどうかは見守る必要がある。
このプロジェクトはもっと良い名前を探すべきだと思う。
実際には Vite を良くしたものというより別のツールの束なので、かなり紛らわしい。
当時の Void Zero は Vite ブランドで収益化しようとしていたのかもしれないが、いまは Cloudflare に買収されたのでその必要もなくなった。
Vite、Vitest、Rolldown、tsdown、Oxlint、Oxfmt を非常に満足して使っている。
ハードフォークしたパッケージも多く、もう戻りたくない。全部ただうまく動く。
名前で混乱するなら、まず Oxlint https://oxc.rs/docs/guide/usage/linter と Rolldown https://rolldown.rs/ を見ればいい。
この6か月で導入したが、tsconfig はほんの少ししか変更していない。
普段は antd6、echart、レンダリングエンジン、地理空間ライブラリのようなものでなければ、新しいパッケージを持ってきて Claude で整理し、厳格で統一された型体系に合わせたうえで、Vite、tsconfig、oxlint の好みに合わせている。
その結果、ライブラリの肥大化やサプライチェーン攻撃の問題を追い続ける必要が減り、読んで直しやすくなった。
Vite は 2022〜2026 年の4年間でメジャーバージョンが5回上がった: 3 → 4 → 5 → 6 → 7 → 8
そのたびに破壊的変更があり、開発者がマイグレーションしなければならなかったが、多すぎる。バージョン 3 の時点と比べて劇的によくなったわけでもないのに。
こうしたレベルの不要な変更と継続的な混乱を、残りの開発ツールチェーンにまで持ち込みたくはない。
Vite+ が結局のところ既存ツールを抽象化されたコマンドラインインターフェースで包むだけなら、望む動作を作るためにさらに多くの間接層をかき分けることになるので、まだ楽観はしていない。
大きな問題は覚えておらず、毎回だいたいそれだけの価値はあった。
破壊的変更はいくつかあったが比較的局所的で、このバージョン間での速度と改善はかなり大きかった。
どんな破壊があったのか気になる。
サーバーサイドレンダリング関連の機能追加は大きな改善だった。
存在しない問題について延々と文句を言うのはやめてほしい。そもそも本当にこれらのツールを使っているのかすら疑わしい。
フロントエンド、あるいは JavaScript エコシステムを追いかけるのは本当に大変。
Laravel で仕事をしていた頃が懐かしいし、Laravel を使う仕事のほうがもっと高給であってほしい
それでも追い続けなければならず、結果にもあまり満足できないかもしれない
以前使っていたものもまだ動く
Laravel 6 の時代が本当に懐かしい
uv でうまくいったやり方なのだから、有能なチームなら JavaScript でも同じことができそう
私にとってはかなり明確な比較対象で、JavaScript エコシステムにとってもとても歓迎すべき進展に感じる。
uv のおかげで Python で作業するのがまた楽しくなった
Vite のように Node ビルドにも使えるのか、それともブラウザ専用なのか気になる
ただし
vite-plugin-nodeを使って NestJS サーバーで Vite を問題なく使っている。例は https://github.com/leosuncin/nest-vite-example/blob/master/v... を参照
基本的には自分をライブラリであるかのように見せればよい
この場合 Vite を開発サーバーとしては使わないが、lint、フォーマット、タスク実行、キャッシュはそのままある
利点は何だろう？ SEA で難読化したい用途なのか？
これにもサブスクリプションが付いているのか気になる。
名前に「+」が付いていると警戒してしまい、当然サブスクリプション付きだと思ってしまう。
見たところ、そうではなさそう
今では「$name+」は「$name の サブスクリプションサービス」という意味として強く刷り込まれている
Astro と一緒に使えるのか気になる