Changesets v3 cuts install size by 88% and switches peer deps from major to patch bump

Seven years after v2, the JavaScript monorepo versioning tool went ESM only, requires Node 22.11+, and changes a behavior that had drawn complaints for years.

Changesets, the MIT-licensed tool used to version packages and generate changelogs in JavaScript monorepos, released its v3.0 on August 11, 2026, the first major release in seven years since v2. Project leadership passed to a team formed by Mateusz Burzyński, Bjorn Lu, and Adam Haglund, who led the migration through a public release plan and today maintains more than 3 million weekly downloads on npm, according to the announcement on InfoQ.

If you work with TypeScript or JavaScript monorepos, chances are you already have a .changeset file in the repository without ever thinking much about it. Changesets is the piece that turns a release intent written in markdown by a contributor into a version bump, a changelog entry, and a publish to the registry, keeping that reviewable inside a pull request. v3 doesn't change that model, but it makes heavy changes to how it runs and to a business rule that had irritated teams for years.

88% smaller install and Node 22.11 as the floor

All packages are now ESM only, which requires Node.js 22.11 or newer, along with pnpm 10, npm 10.9, or Yarn 4.5.2 as minimum versions. Yarn Classic has been discontinued. Behind this cleanup, the team switched the build and test stack to tsdown, rolldown, vitest, and oxfmt, which dropped the install size from 16.1MB to 2.1MB and the number of dependencies from 95 to 39 (the 88% reduction figure comes exactly from that comparison).

Another side effect of the cleanup: Changesets no longer bundles its own copy of Prettier to format changelogs. Now there's the @changesets/format package, which detects and uses Prettier, oxfmt, Deno, or dprint depending on what's already configured in the project, avoiding duplicate formatting dependencies.

For those running CI pipelines with node_modules cache or a fixed container image, this is a direct gain in build time and a smaller supply chain audit surface, not just cosmetics of a faster install.

Peer dependency: from major to patch

The most discussed behavior change is how Changesets handles peer dependencies. Before, when a peer dependency got a bump, every package depending on it automatically received a major bump, even when the change didn't actually break anything. This generated years of complaints, documented in issue 1011 of the repository, where a team maintaining a design system in a monorepo wrote that forcing major in that case "seems to be sending the wrong message and not respecting semver."

In v3, a peer dependency bump now propagates as a patch to dependents, no longer as a major. Whoever is actually shipping a breaking change can still add an explicit major changeset for the dependent package, but the default no longer assumes the worst-case scenario.

Not everyone agrees this is the ideal solution. The maintainers of Bumpy, a recently launched competitor, point out that v3 "hardcodes the opposite extreme," since every peer change is now assumed to be non-breaking by default, and neither tool allows configuring this propagation behavior. Even with that caveat, Bumpy's own comparison acknowledges that v3 resolves old complaints, listing pnpm catalog support and a prerelease design that hasn't changed as the remaining gaps.

What breaks in the migration

The CLI was rebuilt on top of cac for argument parsing and clack for interactive prompts, which fixes a known bug where cancelled prompts would crash the process. Commands and flags were renamed:

# v2
changeset tag
changeset status --sinceMaster

# v3
changeset git-tag
changeset status --since=main

Configuration also changed: the prettier key was replaced by format, and private packages are no longer versioned by default, requiring explicit opt-in:

{
 "format": "auto",
 "privatePackages": { "version": true, "tag": false }
}

There's also a behavior change that catches anyone automating everything without checking the exit code: changeset version now returns exit code 1 when there's nothing to release. A release playbook cited on InfoQ warns that "any script that runs this unconditionally under set -e will now fail on an empty release." It's worth reviewing pipelines that call changeset version directly in a CI job without handling that case.

Two new commands, pack and publish-plan, support the build, pack, and publish sequence recommended by the e18e community, and changesets/action was also updated to v2, exposing sub-actions that let teams using npm's trusted publishing restrict publish permissions per step, instead of granting a broad token to the entire job.

Where Changesets still stands out

Against semantic-release, which infers the version from conventional commits, and release-it, Changesets keeps its most distinctive characteristic: whoever contributes writes the release intent in a markdown file, and that decision stays visible and reviewable inside the pull request before becoming a published version. v3 doesn't touch that model, it just makes it cheaper to install and better behaved around peer dependencies.

For those maintaining a monorepo with multiple packages published to npm, v3's set of changes is essentially welcome housekeeping: less install weight, less noise from undue major bumps, and a few renamed commands that require going through the migration guide before updating the CI. v2 remains maintained on a separate branch for those who can't immediately migrate to the minimum requirements of Node 22.11 and newer package managers.