Vercel CLI

Vercel

開発。プレビュー。デプロイ。

ドキュメント · 変更履歴 · テンプレート · CLI

Vercel

Vercel の AI Cloud は、モダンなアプリケーションを構築するための統合プラットフォームです。チームがインフラストラクチャではなく製品に集中しながら、柔軟に素早く動き、安全性を保つためのツールを提供します。

デプロイ

プロジェクトをインポートするか、テンプレートを選択するか、Vercel CLIを使用して始めましょう。その後、git push でデプロイします。

ネイティブ CLI バイナリ

標準の npm インストールに変更はありません。

npm i -g vercel

ネイティブ CLI バイナリは別途配布されており、vercel npm パッケージには影響しません。ネイティブバイナリを使用し、既存のグローバル vercel および vc コマンドを置き換えるには、ネイティブパッケージを明示的にインストールします。

npm i -g @vercel/vc-native --force

--force フラグを使うと、npm が既存のグローバル vercel および vc のバイナリリンクを置き換えられます。@vercel/vc-native をインストールしない場合は、引き続き npm i -g vercel で通常の Node.js ベースの CLI を使用します。

特定のバイナリが必要な場合は、プラットフォーム固有のパッケージを直接インストールすることもできます。

npm i -g @vercel/vc-native-darwin-x64 --force

ドキュメント

Vercel の使用方法について詳しくは、ドキュメントをご覧ください。

貢献

このプロジェクトでは、依存関係のインストールとスクリプトの実行に pnpm を使用します。

vercel スクリプトを使うと、Vercel CLI を実行するのと同じように、ローカルの変更を実行できます。たとえば、vercel deploy --cwd=/path/to/project は、ローカルの変更を含めて pnpm vercel deploy --cwd=/path/to/project で実行できます。

このリポジトリに貢献する場合は、プルリクエストを送信する前に、まず Vercel Community で、このリポジトリのオーナーと変更内容について話し合ってください。

行動規範を読み、プロジェクトとのすべてのやり取りで遵守してください。

ローカル開発

このプロジェクトはモノレポとして構成されており、1 つのリポジトリに複数の npm パッケージが含まれています。依存関係のインストールと管理には npm CLI ではなく pnpm を使用します。

開始するには、次を実行します。

git clone https://github.com/vercel/vercel
cd vercel
corepack enable
pnpm install
pnpm build
pnpm lint
pnpm test-unit

変更を加える前に、すべてのテストが成功することを確認してください。

Vercel CLI の変更を実行する

cli パッケージから pnpm vercel を使うと、ローカルの変更を含めて Vercel CLI を実行できます。

cd ./packages/cli
pnpm vercel <cli-commands...>

詳しくはCLI のローカル開発をご覧ください。

変更の検証

変更が完了したら（作業と並行して行うこともおすすめします）、次を実行して、すべてのテストが引き続き成功することを確認してください。

pnpm test-unit

プロジェクトのルートから実行してください。

テストが失敗した場合は、変更と併せて修正してください。テストの実行方法、特に統合テストについて詳しくは、テストエラーの解釈をご覧ください。

影響を受けるビルドと型チェックの再現

CI は、プルリクエストのヘッドと、GitHub に記録されたベースおよびヘッドのコミットを比較します。同じ影響対象の Turborepo タスクプランをローカルで確認するには、変更をコミットし、プルリクエストのヘッドをチェックアウトして、SCM の範囲を明示的に指定します。

export TURBO_SCM_BASE=$(gh pr view --json baseRefOid --jq .baseRefOid)
export TURBO_SCM_HEAD=$(gh pr view --json headRefOid --jq .headRefOid)
git fetch origin "$TURBO_SCM_BASE" "$TURBO_SCM_HEAD"
test "$(git rev-parse HEAD)" = "$TURBO_SCM_HEAD"
node utils/gen.js
pnpm exec turbo run ci:checks --affected --dry=json

CI と同じように選択されたタスクを実行するには、最後のコマンドを次のコマンドに置き換えます。

pnpm exec turbo run ci:checks --affected --output-logs=errors-only --summarize --continue

両方のコミットがローカルクローンに存在している必要があります。CI は全履歴をチェックアウトするため、コミットが見つからない場合は変更なしとして扱わず、失敗します。Lint、フォーマット、依存関係のチェック、生成アセットの検証は、引き続きリポジトリ全体を対象に実行されます。

プルリクエストのプロセス

変更が適切に動作することを確認したら、メインリポジトリでプルリクエストを作成してください。

プルリクエストはメンテナーによってレビューされ、テストは継続的インテグレーションプラットフォームで確認されます。

テストエラーの解釈

このリポジトリには、主にユニットテストとエンドツーエンド（E2E）テストの2種類があります。

ユニットテストは主に Vitest で実行され、個々の動作をテストするため、すばやく完了します。

エンドツーエンドテスト

統合テストでは、test プロジェクト名を使って Vercel アカウントにデプロイを作成します。各テストのデプロイ後、probes キーを使って、レスポンスが期待どおりの値かどうかを確認します。値が一致しない場合は、違いを説明するメッセージが表示されます。デプロイのビルドに失敗した場合は、次のような、より一般的なメッセージが表示されます。

[Error: Fetched page https://test-8ashcdlew.vercel.app/root.js does not contain hello Root!. Instead it contains An error occurred with this application.

    NO_STATUS_CODE_FRO Response headers:
       cache-control=s-maxage=0
      connection=close
      content-type=text/plain; charset=utf-8
      date=Wed, 19 Jun 2019 18:01:37 GMT
      server=now
      strict-transport-security=max-age=63072000
      transfer-encoding=chunked
      x-now-id=iad1:hgtzj-1560967297876-44ae12559f95
      x-now-trace=iad1]

このような場合は、失敗したデプロイの URL にアクセスし、末尾に /_logs を追加するとビルドエラーを確認できます。上記の場合は、https://test-8ashcdlew.vercel.app/_logs です。

このデプロイのログには、実際のエラーが記録されており、何が問題だったのかを理解する手がかりになります。

統合テストをローカルで実行する

統合テスト一式をローカルで実行することは推奨しませんが、失敗したテストを自分のマシンで実行して切り分けると役立つ場合があります。そのためには、適切な認証情報がシェルで読み込まれていることを確認してください。

1. アクセストークンを作成します。手順については https://vercel.com/docs/rest-api#creating-an-access-token を参照してください。トークンのスコープが個人アカウントになっていることを確認してください。
2. Vercel ダッシュボードでチーム ID を確認します：https://vercel.com/<MY-TEAM>/~/settings。
3. 次のコマンドで、シェルの rc ファイルに設定を追加します：echo 'export VERCEL_TOKEN=<MY-TOKEN> VERCEL_TEAM_ID=<MY-TEAM-ID>' >> ~/.zshrc

これで、統合テストを実行できるようになります。正常に動作することを確認するため、すでに分離されているテストを選んでください。

cd packages/next

テストを実行します。

pnpm test test/fixtures/00-server-build/index.test.js

メモ

デプロイの取得時にステータスコード 401 が返される場合は、プロジェクトでデプロイ保護を無効にする必要があります。

@vercel/nft

一部の Builder では、デプロイ前にファイルをツリーシェイクするために @vercel/nft を使用します。このツリーシェイクの仕組みに問題があると思われる場合は、プロジェクトに次のスクリプトを作成できます。

const { nodeFileTrace } = require('@vercel/nft');
nodeFileTrace(['path/to/entrypoint.js'], {
  ts: true,
  mixedModules: true,
})
  .then(o => console.log(o.fileList))
  .then(e => console.error(e));

このスクリプトを実行すると、インポートされたすべてのファイルが表示されます。ファイルが見つからない場合、バグは Builder ではなく @vercel/nft にあります。

既存のプロジェクトで Builder をデプロイする

既存のプロジェクトで Builder の変更をテストしたい場合があります。たとえば、vercel dev を使う場合や、実際にデプロイする場合です。Builder の変更を npm に毎回公開せずに済むよう、Builder を tarball としてアップロードできます。

1. 対象の Builder ディレクトリに移動します：cd ./packages/node
2. pnpm build を実行して、TypeScript やその他のビルド手順を実行します。
3. npm pack を実行して tarball ファイルを作成します。ファイルのアクセス許可が保持されないため、pnpm pack は使用しないでください。
4. 作成された tarball をディレクトリに移動します。
5. vercel <directory> を実行して tarball ファイルをアップロードし、URL を取得します。URL の末尾に /<tarball name> を追加してください。
6. 既存の vercel.json プロジェクトを編集し、use を URL に置き換えます。
7. vercel または vercel dev を実行して、実験的な Builder でデプロイします。

注： Builder をダウンロードできるようにするには、設定の「deployment protection」で Vercel 認証を無効にする必要があります。

リファレンス

• 行動規範
• コントリビューションガイドライン
• Apache 2.0 ライセンス