Changesets and SemVer in JavaScript monorepos

Publishing multiple packages from one repo requires discipline: what counts as breaking, how versions line up, and how CI publishes without human error. Changesets (and similar tools) encode intent at PR time and compute versions at release time.

Why not manual npm version#

Manual bumps drift from actual diff summaries, and release notes become copy-paste noise. Changesets ask each PR author: “What packages change and how (major/minor/patch)?”

Fixed vs independent#

• Fixed: one version number for all packages (good for tightly coupled UI kits).
• Independent: each package semver advances on its own (good for loosely related libs).

Pick one model and document it in CONTRIBUTING.md.

Consumer interpretation#

^1.2.0 allows minor and patch updates. A mistaken major bump hurts fewer users than a breaking change shipped as patch—CI should block forbidden bumps via policy or code review checklist.

Automation#

Typical pipeline:

1. Merge changeset files with features.
2. changeset version opens a “Version Packages” PR updating versions and changelogs.
3. On merge to main, changeset publish pushes to npm with provenance (npm OIDC).

Summary#

SemVer is a communication protocol with humans and machines. Changesets reduce release friction in monorepos while keeping changelog quality high—if the team consistently writes human-readable summaries.