Follow-up to #396, which worked around the release failure rather than fixing its cause.
Background
changeset publish on the 2.x line that was pinned here shells out to npm info <pkg> --json to find out what's already on the registry — there was no pnpm code path. npm ≥ 11 validates the root package.json's devEngines on every command, so npm info exited 1 with EBADDEVENGINES ("Invalid name pnpm does not match npm") and the publish died before it started. #396 unblocked releases in the meantime with npm_config_force: true on the changesets step.
@changesets/cli v3 and changesets/action v2 are both stable now (v3.0.0 and v2.0.0 respectively, as of 2026-08-11/12) and are implemented in #401, which does the coordinated bump this issue called for:
@changesets/cli → v3changesets/action@v1 → v2, with the input renames that go with it (publish: → publish-script:, GITHUB_TOKEN env → the github-token: input, defaulting to ${{ github.token }}).changeset/config.json's $schema bumped to @changesets/config@4.0.0
npm_config_force: true is not removable by this upgrade
This issue originally expected the v3 upgrade to let npm_config_force: true be dropped, on the theory that v3's publish pipeline is package-manager-aware and would run pnpm info/pnpm pack/pnpm publish without ever invoking npm. That turned out to be half right: pnpm pack and pnpm publish don't shell out to npm (verified with strace), but pnpm info does — pnpm info <pkg> directly execves npm info <pkg> under the hood, since pnpm implements that subcommand as a passthrough to the real npm CLI rather than its own registry client. changeset publish/changeset publish-plan still call info to check what's already published, so the same EBADDEVENGINES failure #396 worked around still fires — with v3, exactly as with v2.x.
So npm_config_force: true needs to stay on the changesets step indefinitely; there's no changesets- or pnpm-version bump on the horizon that removes the need for it (short of pnpm reimplementing info without shelling to npm, which isn't tracked anywhere). #401 updates the workflow comment accordingly instead of leaving it framed as a removal condition.
Related
Follow-up to #396, which worked around the release failure rather than fixing its cause.
Background
changeset publishon the 2.x line that was pinned here shells out tonpm info <pkg> --jsonto find out what's already on the registry — there was no pnpm code path. npm ≥ 11 validates the rootpackage.json'sdevEngineson every command, sonpm infoexited 1 withEBADDEVENGINES("Invalid namepnpmdoes not matchnpm") and the publish died before it started. #396 unblocked releases in the meantime withnpm_config_force: trueon the changesets step.@changesets/cliv3 andchangesets/actionv2 are both stable now (v3.0.0 and v2.0.0 respectively, as of 2026-08-11/12) and are implemented in #401, which does the coordinated bump this issue called for:@changesets/cli→ v3changesets/action@v1→ v2, with the input renames that go with it (publish:→publish-script:,GITHUB_TOKENenv → thegithub-token:input, defaulting to${{ github.token }}).changeset/config.json's$schemabumped to@changesets/config@4.0.0npm_config_force: trueis not removable by this upgradeThis issue originally expected the v3 upgrade to let
npm_config_force: truebe dropped, on the theory that v3's publish pipeline is package-manager-aware and would runpnpm info/pnpm pack/pnpm publishwithout ever invoking npm. That turned out to be half right:pnpm packandpnpm publishdon't shell out to npm (verified withstrace), butpnpm infodoes —pnpm info <pkg>directlyexecvesnpm info <pkg>under the hood, since pnpm implements that subcommand as a passthrough to the real npm CLI rather than its own registry client.changeset publish/changeset publish-planstill callinfoto check what's already published, so the sameEBADDEVENGINESfailure #396 worked around still fires — with v3, exactly as with v2.x.So
npm_config_force: trueneeds to stay on the changesets step indefinitely; there's no changesets- or pnpm-version bump on the horizon that removes the need for it (short of pnpm reimplementinginfowithout shelling to npm, which isn't tracked anywhere). #401 updates the workflow comment accordingly instead of leaving it framed as a removal condition.Related