release

リポジトリのルートから、set-version.ts の実行後に次を実行します。

releaseVersion=$(node -p "require('./packages/core/package.json').version")
releaseTag="remotion-release-$(printf '%s' "$releaseVersion" | tr . -)"
releaseManifest="/tmp/remotion-release-${releaseVersion}-packages.txt"
bun publish.ts --list > "$releaseManifest"

このマニフェストが、確認および昇格の対象となる正確なパッケージ一覧です。一部の昇格をロールバックできるよう、各パッケージの以前の latest タグを記録します。

マニフェスト内のいずれかのパッケージが npm に初めて公開されるかどうかを確認します。Bun は --tag を指定しても、パッケージの初回公開時に latest を追加します。新しいパッケージがある場合は、一括公開の前に停止し、それらの初回公開を別途計画してください。このフローでは、初回バージョンを latest から外すことはできません。

上で作成したトークンを使用して NPM_CONFIG_TOKEN=<token> bun publish.ts --tag="$releaseTag" を実行します。Bun は引き続きパッケージをパックし、workspace: および catalog: 依存関係を書き換えます。このタグ付きパスは再公開エラーを許容しません。アップロードの成功は、npm のスキャンが完了した証拠にはなりません。マニフェスト、正確なパッケージバージョン、一時タグを確認してください。スキャンが保留中の間は、同じバージョンを再度アップロードしないでください。公開試行が失敗し、そのバージョンが存在しないことが確認された場合は、同じトークンを使用して bun publish.ts --tag="$releaseTag" --only=<package> でそのパッケージのみを再開してください。マニフェスト全体を盲目的に再実行しないでください。

マニフェスト内の各パッケージについて、プロモーションの前に npm view <package>@<version> version --json および npm pack <package>@<version> --pack-destination <temporary-directory> の成功を必須とします。pack チェックは、tarball を実際に取得できることを確認します。パッケージごとのチェックは while read -r p; do ( ... ) & done < "$releaseManifest"; wait ループで実行してください（「command line cannot be assembled」で失敗する xargs -I は使用しないでください）。公開直後は、およそ 3 分の 1 のパッケージがまだ validating であると想定してください。これには約 15 分かかっています。ポーリングループをスクリプトとして記述してバックグラウンドで実行し、その間に changelog を作成してください。未解決のパッケージを約 1 分に 1 回ポーリングします。利用可能な場合は npm lifecycle status API を使用してください: GET https://registry.npmjs.org/-/package/<encoded-package-name>/version/<version>/status を公開アクセス権で認証して使用します。@remotion%2Fwhisper-web のようにスコープ付き名を URL エンコードし、認証情報をログに残さないでください。パッケージが 1 時間経過しても validating のままである場合は、リリースを保留として報告し、すべての latest タグを前回のリリースのままにしてください。blocked、rejected、manual-review、missing、unknown の状態もプロモーションを停止します。これらをスキャンの遅延として扱わず、調査してください。

すべてのパッケージがインストール可能になったら、リリーストークンを使用して、マニフェスト内のすべてのパッケージに対して npm dist-tag add <package>@<version> latest を実行します。npm CLI は NPM_CONFIG_TOKEN を無視し（bun publish のみがこれを尊重します）、ログインセッションにフォールバックして EOTP で失敗します。代わりに次のようにトークンを渡してください: env "npm_config_//registry.npmjs.org/:_authToken=$TOKEN" npm dist-tag add ...。これはパッケージごとに 1 回のレジストリ操作です。npm には複数パッケージのアトミックなプロモーションはありません。すべてのパッケージについて npm view <package> dist-tags.latest --prefer-online がリリースバージョンと一致することを確認してください。並列チェックでは、一部のパッケージについて古いキャッシュされたタグが返されることがあります。失敗として扱う前に、不一致を順次再確認してください。プロモーションが途中で失敗した場合は、すでに変更されたパッケージについて記録された以前の latest タグを復元し、不完全なリリースとして報告してください。プロモーションの成功後、各パッケージから一時タグを削除し、最終的なタグを確認してください。リリーストークンは dist-tag rm で E403 を受け取るため、呼び出しごとに新しい OTP を使用してログインセッションを使用してください: npm dist-tag rm <package> <releaseTag> --otp=$(op item get "Npmjs" --otp --account remotiondev.1password.com)。OTP のロールオーバーにより呼び出しが失敗した場合は、30 秒待ってから 1 回再試行してください。

npm が明示的に E_STAGE_REQUIRED を返した場合、そのパッケージでは直接公開を利用できません。このリリースを停止し、ステージングされたワークフローを別途評価してください。ステージングされた承認にはパッケージごとに 2FA アクションが必要です。ステージングされたパッケージをこの直接公開フローに黙って混在させないでください。