Changesets vs semantic-release: Releases for Monorepos in CI
Changesets uses explicit, authored change files (great for monorepos); semantic-release derives everything from Conventional Commits automatically.
Changesets has contributors add a small changeset file per change describing the bump; a release PR then versions and publishes affected packages - strong for monorepos. semantic-release infers versions and publishes automatically from commit messages.
| Changesets | semantic-release | |
|---|---|---|
| Versioning source | Authored changeset files | Conventional Commits |
| Monorepo support | First-class (per-package) | Possible, more setup |
| Release flow | Release PR (review) | Auto on push |
| Contributor effort | Add a changeset | Write conforming commits |
| Best for | Monorepos, intentional bumps | Single packages, full automation |
In CI
Changesets is built for monorepos: each package is versioned and published from explicit change files via a release PR, giving precise per-package control and a review gate. semantic-release is best for single packages and fully automated publishing from commits. If you maintain many packages in one repo, Changesets usually fits better; for one package with no review step, semantic-release is simpler.
CI setup
Give the release job tokens to publish and version, and for monorepos cache and scope builds to affected packages. The release job runs on CI runners; faster managed runners shorten release builds that bundle or compile many packages.
The verdict
Monorepo wanting explicit, per-package versioning with a review gate: Changesets. Single package wanting fully automated commit-driven releases: semantic-release. Pick by monorepo needs and how much manual intent you want per release.