Follow-up to #396, which worked around the release failure rather than fixing its cause.
Why
changeset publish on 2.x shells out to npm info <pkg> --json to find out what is already on the registry — there is no pnpm code path. npm ≥ 11 validates the root package.json's devEngines on every command, so npm info exits 1 with EBADDEVENGINES ("Invalid name pnpm does not match npm") and the publish dies before it starts (failing run).
Changesets v3 fixes this at the source: its publish pipeline is package-manager-aware and runs pnpm info / pnpm pack / pnpm publish when pnpm is detected, so npm is never invoked and the devEngines check never runs.
#396 unblocked the release in the meantime by setting npm_config_force: true on the changesets step, which downgrades npm's devEngines error to a warning. Completing this upgrade means that env var can be deleted — that is the removal condition recorded in the workflow comment.
What needs to move, together
The CLI cannot be upgraded on its own. v3 dropped the New tag: <pkg>@<version> stdout line that changesets/action@v1 parses to detect what was published; the action's v2 line instead has the CLI write NDJSON git-tag events to $CHANGESETS_OUTPUT and reads that file. CLI v3 with action v1 would publish but report published: false, and push no git tags and create no GitHub releases — a silent regression, worse than today's loud failure. So both move in one PR, or neither does.
Blocker: both are prereleases
As of 2026-08-11:
|
latest stable |
prerelease with the fix |
@changesets/cli |
2.31.1 (still spawns bare npm info) |
3.0.0-next.12 (next tag) |
changesets/action |
v1.9.0 |
v2.0.0-next.4 (2026-08-03) |
So this is two coordinated prerelease majors on the release pipeline — the one pipeline that is awkward to rehearse, since it only exercises the publish path after a Version Packages PR merges. Suggest waiting for both stables unless there's a reason to move sooner; the workaround in #396 holds until then.
Related
Follow-up to #396, which worked around the release failure rather than fixing its cause.
Why
changeset publishon 2.x shells out tonpm info <pkg> --jsonto find out what is already on the registry — there is no pnpm code path. npm ≥ 11 validates the rootpackage.json'sdevEngineson every command, sonpm infoexits 1 withEBADDEVENGINES("Invalid namepnpmdoes not matchnpm") and the publish dies before it starts (failing run).Changesets v3 fixes this at the source: its publish pipeline is package-manager-aware and runs
pnpm info/pnpm pack/pnpm publishwhen pnpm is detected, so npm is never invoked and thedevEnginescheck never runs.#396 unblocked the release in the meantime by setting
npm_config_force: trueon the changesets step, which downgrades npm'sdevEngineserror to a warning. Completing this upgrade means that env var can be deleted — that is the removal condition recorded in the workflow comment.What needs to move, together
The CLI cannot be upgraded on its own. v3 dropped the
New tag: <pkg>@<version>stdout line thatchangesets/action@v1parses to detect what was published; the action's v2 line instead has the CLI write NDJSONgit-tagevents to$CHANGESETS_OUTPUTand reads that file. CLI v3 with action v1 would publish but reportpublished: false, and push no git tags and create no GitHub releases — a silent regression, worse than today's loud failure. So both move in one PR, or neither does.@changesets/cli→ v3 (rootdevDependencies)changesets/action@v1→ v2 in.github/workflows/release.ymlpublish:→publish-script:, and theGITHUB_TOKENenv becomes agithub-token:input (defaults to${{ github.token }}). Also available:version-script,commit-message,pr-title,pr-base-branch,create-github-releases,push-git-tags. Outputs are renamed too (published-packages,has-changesets,pr-number), though we don't currently consume any.npm_config_force: truefrom the step (added in ci: unblock changesets publish from npm's devEngines check #396).changeset/config.jsonagainst the v3 schemaBlocker: both are prereleases
As of 2026-08-11:
@changesets/clinpm info)3.0.0-next.12(nexttag)changesets/actionv2.0.0-next.4(2026-08-03)So this is two coordinated prerelease majors on the release pipeline — the one pipeline that is awkward to rehearse, since it only exercises the publish path after a
Version PackagesPR merges. Suggest waiting for both stables unless there's a reason to move sooner; the workaround in #396 holds until then.Related
^22.11 || ^24 || >=26(we're on 24, fine) and pnpm>= 10per@changesets/cli@3.0.0-next.12'sengines