Changesets vs standard-version: 3 Package Bumps vs 1

I ran standard-version 9.5.0 and Changesets 3.0.3 on the same 3-package npm workspace with 31 commits: standard-version bumped only the root package.json to 1.1.0 and left all 3 packages at 1.0.0, while Changesets bumped core to 1.1.0, ui and cli to 1.0.1, and updated their internal dependency ranges. Changesets also installed 40 packages (4.2 MB) against 191 packages (21.1 MB) for standard-version, which has not shipped a release since May 2022 and now calls itself deprecated in its own README.

Short answer: move monorepos to Changesets. For a single package that already follows Conventional Commits, the maintained fork commit-and-tag-version is the smaller jump. No affiliate links in this post.

What I tested

• Machine: 8 vCPU Intel Xeon / 15 GB RAM shared Linux cloud box, Node 22.20.0, npm 10.9.3, tested 5 Oct 2026 (about 23:59 IST to 00:05 IST on 6 Oct).
• Versions: standard-version 9.5.0 (published 15 May 2022), commit-and-tag-version 13.2.1 (14 Sep 2026), @changesets/cli 3.0.3 (14 Sep 2026).
• Fixture: /workspace/bench-changesets-sv/. Root workspace plus @bench/core, @bench/ui and @bench/cli; ui and cli depend on core. 30 Conventional Commits spread across the three packages (feat, fix, perf, refactor, docs, chore), tagged v1.0.0 before them. Three changeset files: core minor, ui patch, cli patch.
• Runs: standard-version and commit-and-tag-version with --skip.commit --skip.tag; changeset version (which does not commit by default). Each run used a fresh copy of the repo. One warm-up, then 7 interleaved rounds.
• Install footprint: each tool alone in an empty project with a warm npm cache.
• Findings: release-step medians 267 ms (standard-version), 239 ms (commit-and-tag-version), 148 ms (Changesets). Installs: 191, 68 and 40 packages; 21.1 MB, 8.4 MB and 4.2 MB.
• One surprise: changeset init in 3.0.3 is now interactive (four prompts), so a scripted setup hung until I wrote .changeset/config.json by hand.
• Not tested: publishing to npm, GitHub release creation, release-please, semantic-release, pnpm or Yarn workspaces, pre-release modes, Windows or macOS.

Does standard-version handle a monorepo?

Result on a 3-package workspace	standard-version 9.5.0	commit-and-tag-version 13.2.1	Changesets 3.0.3
Root package.json	1.0.0 to 1.1.0	1.0.0 to 1.1.0	unchanged (private root)
@bench/core	1.0.0 (unchanged)	1.0.0 (unchanged)	1.1.0
@bench/ui and @bench/cli	1.0.0 (unchanged)	1.0.0 (unchanged)	1.0.1 each
Internal dependency on core	not touched	not touched	updated to 1.1.0
Changelog	one root file, 18 entries	one root file	one per package
Release step median (7 runs)	267 ms	239 ms	148 ms

Not out of the box. Both standard-version and its fork read every commit since the last tag and bumped the root. The 18 changelog entries from three packages landed in one file under shared Features and Bug Fixes headings. That works if you publish one artifact. It does not work if core, ui and cli ship to npm on their own versions.

Changesets did what a monorepo needs: per-package bumps, a dependency cascade from core into ui and cli, and three separate CHANGELOG.md files. If you also run a task runner across those packages, my Turbo vs Nx and Turbo vs Lage timings cover that layer.

Is speed a reason to pick one?

No. All three finished the version step in under 300 ms on this repo. The difference you will notice is install weight and what the tool writes, not runtime.

Install size matters more in CI. standard-version pulled in 191 packages; Changesets pulled in 40. If you are trimming devDependencies anyway, my knip vs depcheck test helps find what else can go.

Is standard-version still safe to keep?

It still ran cleanly on Node 22, and nothing broke in my test. But the README opens with "standard-version is deprecated", the last release was 9.5.0 in May 2022, and the author points GitHub users to release-please. That means no fixes if a future Node or conventional-changelog change breaks it.

One small wart I hit: with no git remote set, its changelog heading linked to "///compare/v1.0.0...v1.1.0". Real repos with a remote will not see that, but it shows the template assumes hosted git.

Which release tool should you switch to?

Situation	My pick
Monorepo, packages published separately	Changesets
Monorepo, internal dependencies between packages	Changesets
Single package, Conventional Commits already enforced	commit-and-tag-version (same flags worked here)
You want release notes written by humans per PR	Changesets
You want versions computed from commits with no extra files	commit-and-tag-version
GitHub-only and you want release PRs	release-please (README pick; I did not test it)

Bottom line: 3 correct package bumps against 1 root bump is the deciding number for a monorepo, and 40 against 191 dependencies is a bonus. Who should not switch to Changesets: single-package projects where every commit already follows the Conventional Commits format, because Changesets adds a changeset file per change that someone has to write. If you enforce commit messages with git hooks, see Lefthook vs Husky; for keeping versions aligned across workspaces, see syncpack vs npm-check.

How this was made: I built a 3-package npm workspace with 31 commits on the ShopperCove test box, ran each release tool on fresh copies, recorded versions, changelogs and timings, and kept the JSON; the write-up was drafted with AI help and checked against that output.

Sources

• https://github.com/changesets/changesets
• https://www.npmjs.com/package/@changesets/cli
• https://github.com/conventional-changelog/standard-version
• https://www.npmjs.com/package/standard-version
• https://github.com/absolute-version/commit-and-tag-version
• https://www.conventionalcommits.org/en/v1.0.0/

Related

• https://www.shoppercove.com/blog/turbo-vs-nx
• https://www.shoppercove.com/blog/turbo-vs-lage
• https://www.shoppercove.com/blog/syncpack-vs-npm-check
• https://www.shoppercove.com/blog/lefthook-vs-husky
• https://www.shoppercove.com/blog/knip-vs-depcheck
• https://www.shoppercove.com/blog/ncu-vs-npm-outdated
• https://www.shoppercove.com/blog/pnpm-vs-npm-vs-bun
• https://www.shoppercove.com/blog/volta-vs-fnm