Vite+ AIエージェント開発のための優れたツールチェーン

Vite+ がAIエージェントを使ったアプリケーション開発の方法を変えた

あるプロジェクトでは、47個の開発依存関係、7つの設定ファイル、そしてエージェントにすべてを実行させる方法を説明するMarkdownファイルがありました。午前2時に、ローカルチェックとCIの違いをデバッグしていました。コードは完成していましたが、それを囲むツール群はそうではありませんでした。Vite+ を4つのプロジェクトで3週間使った後、新しいViteアプリに対する私のルールはシンプルになりました。それをAIに与える最初のプロンプトに入力することです。

短く言うと

• 新しいViteアプリの場合、エージェントに vp create でプロジェクトを作成させ、その後 vp check、vp test、vp build でその作業を確認させます。
• スピードも良いですが、私にとってのより大きな収穫は、エージェント、私、CIにとって明確なワークフローが一つできたことです。
• 既存のプロジェクトの場合、vp migrate を移行の開始点として扱います。差分、テスト、ビルドの動作は引き続きレビューします。

遅いリンターは問題ではなかった

私のコマンドは、ESLint、Prettier、TypeScript、テストランナー、package.json スクリプトに分散していました。エージェントをプロジェクトに導入したとき、その最初の仕事は正しいコマンドがどれかを把握することでした。それを説明するために指示を書きました。今では、保守するファイルがもう一つ増えたのです。素晴らしい時間節約ですよね？

ファイルの数だけではありませんでした。一度、ローカルセットアップとCIが生成されたファイルを異なる方法でチェックしました。エージェントは一つの結果を見ましたが、パイプラインは別の結果を見ました。より速いコンポーネント生成もそれを解決しません。

Vite+ は日常的なタスクを vp の下に集約します：開発とビルドのためのVite、テストのためのVitest、チェックのためのOxlintとOxfmt、ライブラリのためのtsdown、タスクのためのVite Taskです。これらの設定は vite.config.ts に保持できます。package.json、tsconfig、そしてプロジェクトによってはフレームワークの設定も引き続き使用します。「すべてを一つのファイルに」というのは、バナーには良くても、実際のリポジトリでは悪いでしょう。

Reactアプリの場合、プロジェクト作成後に必要なコマンドは以下の通りです。

1vp create vite -- --template react-ts 2cd project-name 3vp install 4vp dev 5vp check 6vp test 7vp build

上記のコマンドは vp がグローバルで利用可能であることを前提としています。グローバルインストールはオプションです。ローカル依存関係としてパッケージマネージャー経由でVite+を実行することもできます。vp install はプロジェクトで選択されたパッケージマネージャーを使用するため、Vite+ は npm や pnpm を置き換えるものではありません。

［画像: プロジェクト設定中に Vite+ を作成するターミナル出力］

vp create でプロジェクトを作成する。

エージェントに「完了」の意味を推測させない

Vite+ のドキュメントには、AIアシスタント向けのプロンプトが含まれています。これは有用な出発点ですが、私はそれをプロジェクトに合わせて調整します。私の目標は具体的です。エージェントはVite+ を使ってアプリをセットアップすべきであり、最初のページを生成した後に静かに放棄すべきではありません。

Vite+ を使用して、Vite 上に新しい React + TypeScript アプリを作成してください。まず、現在の `vp create` ガイドを読み、`vp help create` を実行してください。ターゲットディレクトリを検査し、既存のファイルを上書きしないでください。現在の安定版 Vite+ リリースと1つのパッケージマネージャーを選択してください。React + TypeScript テンプレートを使用して `vp create` でプロジェクトを作成してください。その単一のロックファイルを保持してください。特別な理由がない限り、別のリンターやフォーマッターを追加しないでください。セットアップ後、`vp install`、`vp check`、関連するテストを `vp test` で実行し、本番用の `vp build` を実行してください。実装した動作に対するテストを追加してください。チェックが失敗した場合は、原因を修正して再実行してください。最終レポートでは、Vite+ のバージョン、コマンド、および実際の結果をリストしてください。

私はすべてのプロジェクトで curl を介したグローバルインストールを要求しません。一度きりのセットアップには、npx --package=vite-plus@1.3.0 vp create のようなものが十分です。確立されたプロジェクトでは、エージェントは選択されたパッケージマネージャーを通じてローカルCLIを実行できます。create-vite を禁止しているわけでもありません。vp create vite はそのテンプレートを使用します。重要なのは、エージェントが意図されたセットアップに従い、一貫したツールチェーンを維持することです。

エージェントに自由裁量を与えたところ、Prettier と Ox fmt の両方、3つのロックファイル、そして信頼性の低いCIを持つことになりました。2番目のフォーマッターを禁止し、1つのロックファイルを要求することは、美的嗜好ではありません。これらは、私が再びクリーンアップしたくない2つの間違いです。

1つのコマンドで迅速なフィードバックが得られる

コードを変更した後、vp check を実行します。これはフォーマットとlintをチェックし、設定で typeAware と typeCheck の両方が有効になっている場合はTypeScriptもチェックします。vp create で作成された新しいプロジェクトでは、デフォルトでこれらが有効になります。既存のプロジェクトでは、緑色の結果を仮定する代わりに、その設定を確認して、型が健全であることを確認します。

私の古いワークフローとの違いは次のとおりです。

1# 前: プロジェクトごとのスクリプトに依存していました。
2npm run format:check
3npm run lint
4npm run typecheck
5
6# 現在、対応する Vite+ 設定を持つプロジェクトで。
7vp check

vp check --fix は一部の検出結果を自動的に修復できます。その後、差分を読み、再度チェックを実行します。緑色のlint結果でも、アプリが正しいことを行っているかどうかはわかりません。動作には vp test、アプリケーションがビルドされることを確認するには vp build が必要です。

私はそのルールをリポジトリのエージェント指示にも含めました。1週間後にプロジェクトに戻ったとき、新しいエージェントは昨日のチャットを覚えていないでしょう。リポジトリはコマンドを覚えています。

1## タスク完了前のチェック
2
3- コードを変更した後、`vp check` を実行し、エラーがあれば修正してください。
4- 動作を変更した後、関連するテストを `vp test` で実行してください。
5- Vite アプリを引き渡す前に、`vp build` を実行してください。
6- 自動修正の後、差分を確認してください。
7- 失敗した実行を完了と見なさず、実際の結果を報告してください。

ローカルの指示とGitフックは役立ちますが、バイパスされたり無効にされたりする可能性があります。CIでも同じチェックを実行します。私がエージェントに unattended で作業させた実験では、マージ前の人間のレビューは依然として私の責任でした。

測定したもの

モノレポでは、ワークフローを変更した後、CIが4分から50秒に短縮されました。コミット前のチェックは11秒から2秒未満に短縮されました。これらは私のプロジェクトからの結果であり、同一条件下で Vite+ と他のツールチェーンを比較したベンチマークではありません。パフォーマンス向上のいくつかは、何が実行され、どのファイルがチェックされるかに起因します。異なる設定でこれらのCI時間を自動的に得ることはできません。

［画像: GitHub Actions ベンチマーク出力：クラシックなツールチェーン、10.441秒］

GitHub Actions: クラシックなツールチェーンのベンチマークは10.441秒かかりました。

［画像: GitHub Actions ベンチマーク出力：Vite+、1.356秒］

GitHub Actions: Vite+ のベンチマークは1.356秒かかりました。

変更されたファイルの迅速なチェックのために、vp staged と vp hooks で管理されるGitフックを使用します。異なるプロジェクトが異なる動作をする場合、vp toolchain はそれらのアクティブなバージョンを示します。vp toolchain --global はグローバルインストールを示します。「確実に更新した」という私の古い方法よりもデバッグに役立ちます。

［画像: vp staged --verbose のターミナル出力］

vp staged でステージングされたファイルをチェックする。

［画像: Vite+ ツールバージョンを示す vp toolchain のターミナル出力］

vp toolchain はプロジェクト内のアクティブなツールバージョンを示します。

モノレポでは、2つのことを区別する必要があります。vp run は package.json スクリプトまたは vite.config.ts で定義されたタスクを実行し、ワークスペースの依存関係に応じて作業を順序付けることができます。package.json スクリプトではキャッシュは自動的に有効になりません。 例えば vp run --cache build で有効にできます。vite.config.ts で定義されたタスクはデフォルトでキャッシュされます。vp run だけでビルドが常に速くなるという約束をCIのタイミングにするつもりはありません。

厄介だった点

vp migrate は古いモノレポで約4分間実行されました。ESLint、Prettier、元のtsupビルドセットアップを変換しましたが、私のケースでは何も壊れませんでした。これはすべての移行が4分かかるという意味ではありません。結果を古いlint、テスト、フック、ビルド出力と比較する必要があります。プラグインやカスタムルールは手動作業が必要な場合があります。

もう一つの落とし穴は、組み込みコマンドとプロジェクトスクリプトの違いです。vp build はViteアプリのビルドを実行します。vp run build は package.json の build スクリプトまたはその名前のタスクを実行します。Next.jsプロジェクトでは、エージェントは vp build が next build を置き換えると仮定してはなりません。同じ区別が vp dev と vp run dev にも適用されます。Vite+ は他のテンプレートでも動作しますが、それらのコマンドの動作が変わるわけではありません。

3番目の問題はバージョン管理です。グローバルな vp env はNode.jsとパッケージマネージャーを管理できます。私は3つのプロジェクトを3つのNodeバージョンで実行しており、切り替えが容易になりました。これを望まない場合は、vp env off で無効にできます。vp upgrade はグローバルCLIを更新します。すべてのプロジェクトのローカル vite-plus パッケージを自動的に更新するわけではありません。 コマンド名が逆の仮定を招くため、エージェントの指示にこれを明記しました。

最初のプロンプトで Vite+ を誰に含めるか

AIがセットアップを行う新しいViteアプリを開始する人全員です。標準化のコストはここでは小さいです。1つのツールチェーンを選択し、チェックコマンドをリポジトリとCIに配置し、エージェントはコード変更から検証までの明確なパスを得られます。3週間と4つのプロジェクトを通して、私にとっての主な利点は、基本的なコマンドを繰り返し説明するのをやめたことでした。

動作中のビルドとテストスイートを持つ大規模な既存アプリを盲目的に移行することはありません。フレームワークに独自のビルドがある場合、まずVite+ のどの部分を実際に使用したいかを決定します。そして、すでに文書化され、高速で安定したスタックを持っている場合、「1つのコマンド」という約束だけではそれを置き換えるようには説得されません。

次にViteプロジェクトを開始するときは、最初のプロンプトに vp create を含め、完了の定義の一部として vp check、テスト、ビルドの出力を要求してください。完成したアプリのスクリーンショットは良いものです。チェックをパスすることが、より多くのことを教えてくれます。