CHANGESETS.md
Trigger.dev uses changesets to manage package versions and releasing them to npm. For server-only changes, we use a lightweight .server-changes/ convention.
Changesets and .server-changes/ files are user-facing release notes, not a catalog of every change. Add one only when the change is something a user would notice or act on. Skip it for internal-only changes, refactors, chores, and packages that are not consumed independently (e.g. @trigger.dev/redis-worker). Anyone who wants the exact history reads the commits.
To add a changeset, use pnpm run changeset:add and follow the Changesets adding-a-changeset guide. Please only ever select one of our public packages when adding a changeset.
If your PR only changes server components (apps/webapp/, apps/supervisor/, etc.), does NOT change any published packages, AND the change is user-facing, add a .server-changes/ file instead of a changeset:
cat > .server-changes/fix-batch-queue-stalls.md << 'EOF'
---
area: webapp
type: fix
---
Speed up batch queue processing by removing stalls and fixing retry race
EOF
area: webapp | supervisortype: feature | fix | improvement | breakingFor mixed PRs (both packages and server): the changeset covers it, so no .server-changes/ file is needed. If the package change is internal and needs no changeset but the server change is user-facing, add a .server-changes/ file for it.
See .server-changes/README.md for full documentation.
Only for user-facing changes. Skip the note entirely for internal-only or admin-only changes, refactors, and chores.
| PR changes | What to add |
|---|---|
Only packages (packages/ or integrations/) | Changeset (pnpm run changeset:add), if the package change is user-facing |
Only server (apps/) | .server-changes/ file, if the server change is user-facing |
| Both packages and server | The changeset covers it; if the package change needs no changeset but the server change is user-facing, add a .server-changes/ file |
Please follow the best-practice of adding changesets in the same commit as the code making the change with pnpm run changeset:add, as it will allow our release.yml CI workflow to function properly:
main branch, the changesets-pr.yml workflow will run and will automatically create/update a PR with a fresh run of pnpm run changeset:version..server-changes/ entries..server-changes/ files are removed on the changeset-release/main branch — the same way changesets deletes .changeset/*.md files. When the release PR merges, they're gone from main.main, the release.yml workflow will automatically build, release packages to npm, and create a single unified GitHub release.pnpm run changeset:addpnpm run changeset:nextpnpm run changeset:versionpnpm run changeset:releasepnpm run changeset:normal.changeset/config.json file to set the "changelog" field to this:"changelog": "@changesets/cli/changelog",
Do a temporary commit (do NOT push this, you should undo it after)
Run ./scripts/publish-prerelease.sh prerelease
You can choose a different tag if you want, but usually prerelease is fine.