| name | changeset |
| description | Author a Changesets changeset (a `.changeset/*.md` file) for the current changes. Use this whenever a change touches publishable library source under `packages/` and is about to be committed or opened as a PR, or whenever the user mentions a changeset, a version bump, release notes, or asks "what bump should this be". This repo uses Changesets (not Lerna/conventional-commit bumps), and CI fails any PR that changes a publishable package without a changeset — so adding one is part of finishing a change, even if the user didn't say "changeset" explicitly. |
Authoring a changeset
This repo releases with Changesets: every PR that changes a publishable package
carries a small .changeset/*.md file declaring which packages bump and by how much.
changeset version later consumes those files into per-package CHANGELOG.mds and
version bumps. No changeset → no release for that change; changeset-bot comments a
reminder on the PR (a nudge, not a hard block — the maintainer-reviewed Version PR is the
real gate). Your job here is to write a correct changeset for the work in progress.
Steps
-
See what changed. Fetch and diff against the base branch:
git fetch origin main
git diff --name-only origin/main...HEAD
(Use the working tree too if changes aren't committed yet: git status.)
-
Map files → packages. A file under packages/<dir>/ belongs to that package.
Read references/bump-rules.md for this repo's publishable vs private/ignored
package list and the dependency graph. Only publishable packages need a changeset.
-
Decide the bump per package. On this 0.x line: fix:/feat: → patch, a
breaking change → minor (a stable 1.0.0 is a separate, deliberate cut). See
references/bump-rules.md for the full rationale (and why you should not list
cascade-only dependents).
-
Write the file. Create .changeset/<short-kebab-name>.md in the exact frontmatter
format from references/format.md. The summary becomes the changelog line, so write it
for a reader of the release notes, not a commit log — 1–2 lines max, short but
descriptive.
-
Confirm. Run pnpm changeset status to verify Changesets sees your file and the
intended packages bump (including the automatic dependent cascade).
-
Commit and push it. A changeset only counts once it's on the PR — don't leave it as
a loose working-tree file. Commit and push to the current branch:
git add .changeset/*.md
git commit -m "chore: add changeset"
git push
Pushing to the PR's head branch updates the open PR automatically.
Key rules (full detail in references/)
- Only declare packages you intentionally changed. Internal dependents re-release
automatically (
updateInternalDependencies: patch); authoring changesets for them
double-counts and produces noisy changelogs.
- Skip docs-only, chore-only, test-only, and private-package-only changes. For a
deliberately release-less change,
pnpm changeset --empty.
- One changeset can cover multiple packages; use multiple changesets if different parts of
the work deserve different changelog entries.
