Changesets vs standard-version: 3 Package Bumps vs 1
standard-version 9.5.0 vs Changesets 3.0.3 (plus fork commit-and-tag-version 13.2.1) on a 3-package npm workspace with 31 commits: standard-version bumped only root to 1.1.0; Changesets bumped core 1.1.0, ui/cli 1.0.1 and internal deps. Installs: 191 pkgs / 21.1 MB vs 40 pkgs / 4.2 MB. Version step 267 ms vs 148 ms.
5 min read
Hands-on
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
- 01github.com/changesets/changesets
- 02npmjs.com/package/@changesets/cli
- 03github.com/conventional-changelog/standard-version
- 04npmjs.com/package/standard-version
- 05github.com/absolute-version/commit-and-tag-version
- 06conventionalcommits.org/en/v1.0.0/
Related
Lab evidence
What I found running this
Hands-on on ShopperCove box 5 Oct 2026 ~23:59 IST to 6 Oct ~00:05 IST (8 vCPU Intel Xeon / 15 GB shared Linux, Node 22.20.0, npm 10.9.3). Fixture: /workspace/bench-changesets-sv/template - private root workspace + @bench/core, @bench/ui, @bench/cli (ui/cli depend on core), tag v1.0.0 then 30 conventional commits, 3 changeset files (core minor, ui/cli patch). Tools: standard-version 9.5.0 (May 2022, README says deprecated), commit-and-tag-version 13.2.1, @changesets/cli 3.0.3. Fresh repo copy per run; 1 warm-up + 7 interleaved: medians sv 267 ms, catv 239 ms (--skip.commit --skip.tag), changeset version 148 ms. sv/catv bumped root only, one CHANGELOG with 18 entries (6 feat, 12 fix); Changesets bumped core 1.1.0, ui/cli 1.0.1, internal deps to 1.1.0, 3 CHANGELOGs. Installs alone: 191/68/40 pkgs, 21.1/8.4/4.2 MB. changeset init 3.0.3 is interactive; config written by hand. Raw: /workspace/bench-changesets-sv/res-changesets-sv.json. Not tested: npm publish, GitHub releases, release-please, semantic-release, pnpm/Yarn, pre mode, Windows/macOS. No affiliate.
Keep reading
Python partition vs split: Which One Should You Use?
Both cut a string at a separator, but they fail in different ways. We ran them on Python 3.13.5 to show where partition() is safer and where split() is the right tool.
Summary2 Nov 20263 min read
toSorted vs sort JavaScript: Which One Copies Your Array?
What changes when you swap sort() for toSorted(), with a real 1-million-item Node.js benchmark and the support table.
Summary1 Nov 20263 min read
How to Reorder a YouTube Playlist, and Why Won't It Drag?
Dragging videos is the official way to change a playlist's order. Here are the steps from YouTube Help, where to find them in YouTube Studio, and the cases where reordering will not work.
Summary31 Oct 20263 min read
