release

Kill any
```
turbo
```
processes that might be running with SIGKILL
Before beginning the release, verify that gcloud is logged in by running
```
gcloud auth print-access-token >/dev/null
```
. If it fails, run
```
gcloud auth login
```
, then repeat the check. Do not continue with the release until the check succeeds.
Codex-specific: Before running release commands, make sure rbenv wins over the macOS system Ruby. Codex may start non-interactive shells with
```
/usr/bin
```
before
```
~/.rbenv/shims
```
, causing Ruby 2.6 to be used even though the user's terminal uses Ruby 3.3.x. Run release commands that may invoke Ruby/Bundler with:
```
PATH="$HOME/.rbenv/shims:$HOME/.rbenv/bin:$PATH" <command>
```
Verify with
```
PATH="$HOME/.rbenv/shims:$HOME/.rbenv/bin:$PATH" ruby --version
```
; it should use the user's rbenv Ruby, not
```
/usr/bin/ruby
```
. This matters because the lambda Ruby package currently resolves gems such as
```
json
```
that require Ruby >= 2.7.
Check
```
npm whoami
```
. Only if it fails, run
```
npm login
```
(I will manually do 2FA in the browser)

Use

op item get "Npmjs" --fields password --reveal --account remotiondev.1password.com

to get the password for NPM.

Use

op item get "Npmjs" --otp --account remotiondev.1password.com

to get a one-time password for 2FA.

Run
```
npm token create --name="PublishRemotionXXXXXX" --packages "remotion" --packages "create-video" --packages-and-scopes-permission read-write --bypass-2fa --scopes "@remotion" --otp=<otp>
```
. Replace XXXXXX with a random string so we have a unique name. Use
```
op item get "Npmjs" --otp --account remotiondev.1password.com
```
to get the OTP and pass it via
```
--otp=
```
. It will ask for a password, pipe in the password using
```
echo "$PASSWORD" |
```
.
- Do not pass
```
--json
```
  : npm masks the token as
```
npm_***
```
  in JSON output, making it unusable. Redirect the plain output to a file in the scratchpad and extract the token with
```
grep -oE 'npm_[A-Za-z0-9]{20,}'
```
  into a scratchpad file (e.g.
```
$SP/npm_token
```
  ). Never print the token. If a token turned out unusable, revoke it with
```
npm token revoke <id> --otp=<otp>
```
  (find the id with
```
npm token list
```
  ).
Run
```
bun i
```
Run
```
bun run build
```
Run
```
npm view remotion version
```
to get the current version number
Run
```
bun set-version.ts <version>
```
, where <version> is the current version plus 1. If the exit code is not 0, abort the entire release process immediately. Do not pipe its output (e.g. into
```
tail
```
): the shell is zsh, so
```
$PIPESTATUS
```
is unavailable and the exit code gets lost. Redirect to a log file instead, then confirm the
```
v<version>
```
commit and tag exist.

Run

cd packages/example && sh runlambda.sh && cd ../..

. If this fails, abort the release.

Publish the public packages under a temporary npm dist-tag, then promote
```
latest
```
only after every package is installable.
```
validating
```
is npm's automatic scan for ordinary publishes, not a reason to use
```
npm stage
```
. Do not run
```
bun run release
```
: its current script publishes directly to
```
latest
```
and starts private publishing and Git pushes before the availability gate.
- From the repository root, after
  set-version.ts
  , run:
  bash
```
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"
```
  The manifest is the exact package list to check and promote. Record each package's previous
  latest
  tag so a partial promotion can be rolled back.
- Check whether any package in the manifest is being published to npm for the first time.
  Bun adds
  latest
  to a package's initial publish even with
  --tag
  . If there are new packages, stop before the bulk publish and plan their first publication separately; this flow cannot keep their first version off
  latest
  .
- Run
  NPM_CONFIG_TOKEN=<token> bun publish.ts --tag="$releaseTag"
  with the token created above. Bun still packs the packages and rewrites
  workspace:
  and
  catalog:
  dependencies. This tagged path does not tolerate republish errors. A successful upload is not proof that npm's scan is finished: check the manifest, exact package versions, and temporary tags. Do not upload the same version again while its scan is pending. If a publish attempt failed and the version is confirmed absent, resume that package alone with
  bun publish.ts --tag="$releaseTag" --only=<package>
  using the same token; never rerun the entire manifest blindly.
- For each package in the manifest, require
  npm view <package>@<version> version --json
  and a successful
  npm pack <package>@<version> --pack-destination <temporary-directory>
  before promotion. The pack check confirms the tarball can actually be fetched. Run the per-package checks with a
  while read -r p; do ( ... ) & done < "$releaseManifest"; wait
  loop (not
  xargs -I
  , which fails with "command line cannot be assembled"). Right after publishing, expect roughly a third of the packages to still be
  validating
  ; this has taken ~15 minutes. Write the polling loop as a script and run it in the background, and draft the changelog meanwhile. Poll unresolved packages about once per minute; use the npm lifecycle status API where available:
  GET https://registry.npmjs.org/-/package/<encoded-package-name>/version/<version>/status
  , authenticated with publish access. URL-encode scoped names, such as
  @remotion%2Fwhisper-web
  , and keep credentials out of logs. If a package remains
  validating
  after an hour, report the release as pending and leave every
  latest
  tag on the prior release. Blocked, rejected, manual-review, missing, and unknown states also stop promotion; investigate them rather than treating them as scanning delays.
- Once all packages are installable, use the release token to run
  npm dist-tag add <package>@<version> latest
  for every package in the manifest. The npm CLI ignores
  NPM_CONFIG_TOKEN
  (only
  bun publish
  respects it) and falls back to the login session, failing with
  EOTP
  . Pass the token like this instead:
  env "npm_config_//registry.npmjs.org/:_authToken=$TOKEN" npm dist-tag add ...
  . This is one registry operation per package; npm has no atomic multi-package promotion. Verify that
  npm view <package> dist-tags.latest --prefer-online
  equals the release version for every package. Parallel checks can return stale cached tags for a few packages; recheck mismatches sequentially before treating them as failures. If promotion fails partway, restore the recorded previous
  latest
  tags for packages already changed and report the incomplete release. After a successful promotion, remove the temporary tag from each package and verify the final tags. The release token gets
  E403
  on
  dist-tag rm
  , so use the logged-in session with a fresh OTP per call:
  npm dist-tag rm <package> <releaseTag> --otp=$(op item get "Npmjs" --otp --account remotiondev.1password.com)
  . If a call fails because the OTP rolled over, wait 30 seconds and retry once.
- If npm explicitly returns
  E_STAGE_REQUIRED
  , direct publishing is unavailable for that package. Stop this release and assess a staged workflow separately; staged approval requires a 2FA action per package. Do not silently mix a staged package into this direct-publish flow.
Only after all public
```
latest
```
tags are verified, run
```
bunx turbo run publishprivate --concurrency=1
```
, then
```
git push --tags
```
and
```
git push
```
from the repository root. If any step fails, stop and report the affected release state.
Run
```
bun run publishtemplates
```
from the repository root to republish every template after the public packages have been promoted. If any template fails to publish, stop the release workflow and report the failure.
Generate a changelog in markdown and save it to
```
/tmp/release-<version>.md
```
:
- Run
```
git log v<previous_version>..v<new_version> --oneline
```
  to get all commits
- Extract PR numbers from merge commits
- For each PR, run
```
gh pr view <number> --json title,author,number,url --jq '"* \(.title) by @\(.author.login) in \(.url)"'
```
- Categorize PRs into sections: "What's Changed", "Templates", "Docs", "Internal"
- Also use the "Elements" and "Internal and Experimental" sections when previous releases do
- In "What's Changed", put headline features (especially ones with new docs pages) first, then sort items so that entries for the same package are adjacent (no subheadings, just sorted order). Changes to the
```
remotion
```
  core package should appear first
- Strip redundant prefixes from PR titles (e.g. remove "Docs:" from items in the Docs section)
- Linkify items whose PR added a new documentation page: run
```
git diff --diff-filter=A --name-only v<previous_version>..v<new_version> -- 'packages/docs/docs/**/*.mdx' 'packages/docs/docs/**/*.md'
```
  to list added docs pages, map each added page to the PR that introduced it, and wrap that item's title in a markdown link to the page (e.g.
```
* [<title>](https://remotion.dev/docs/<slug>) by @author in <url>
```
  ). Determine the URL from the page's
```
slug:
```
  frontmatter if present, otherwise from its file path relative to
```
packages/docs/docs/
```
  . Leave items without a new docs page unlinked.
- "Templates" is a separate section for any template-* changes
- Check for genuinely new contributors by running
```
gh api repos/remotion-dev/remotion/contributors --paginate --jq '.[].login'
```
  and comparing against PR authors. Only add a "New Contributors" section for authors not in that list
- Add
```
**Full Changelog**: https://github.com/remotion-dev/remotion/compare/v<previous_version>...v<new_version>
```
  at the bottom
- Use the same format as previous GitHub releases (check with
```
gh release view v<previous_version>
```
  )
- Don't release until you get approval. Allow me to edit it before. This does not block the npm steps: draft the changelog while npm scans packages, and continue with promotion, private publishing, pushes and templates without waiting.
- After approval, re-read
```
/tmp/release-<version>.md
```
  (I may have edited it) and run
```
gh release create v<version> --title v<version> --notes-file /tmp/release-<version>.md --verify-tag
```
  .
Finally, delete the local copies of the npm token from the scratchpad. It expires by itself after 7 days.

release

NPX Install

Tags

SKILL.md Content