Fixed handling of the npm 12 info output - #2159
Conversation
🦋 Changeset detectedLatest commit: 149fd91 The changes in this PR will be included in the next version bump. This PR includes changesets to release 1 package
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## maintenance/v2 #2159 +/- ##
==================================================
+ Coverage 83.85% 83.86% +0.01%
==================================================
Files 56 56
Lines 2465 2467 +2
Branches 743 744 +1
==================================================
+ Hits 2067 2069 +2
Misses 392 392
Partials 6 6 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
|
This is already being fixed in #2097 but that's in the works and targets the upcoming (soon!) v3 release. Given this is a pretty big break for npm users, we can definitely accept a PR targeting v2 - but that should be opened against the maintenance/v2 branch. |
a6f0607 to
5fc2fb7
Compare
Awesome! Looking forward to check out v3!
I've retargeted this PR to be based on and point towards |
… detection npm v12's `npm info --json` always returns an array, which @changesets/cli 2.31.0 misparses as 'never published': it re-attempts every already-published version, the registry refuses (cannot publish over previously published), and the publish step exits 1 on every train (first seen on the 2.7.0 release, reproduced on rerun; the publishes themselves succeeded — the red came from the re-attempts). The workflow installed npm@latest, which moved from 11.x to 12.x between the 2.6.1 (green) and 2.7.0 (red) trains. Pin the 11.x line (OIDC Trusted Publishing needs >= 11.5.1); restore @latest once changesets/changesets#2159 ships.
| // npm 12 emits an E404 error instead of empty stdout when nothing | ||
| // matches `latest` (e.g. GitHub Packages without a `latest` dist-tag) |
There was a problem hiding this comment.
tbh, I can't reproduce this - and the npm's source code seems to back that up:
https://github.com/npm/cli/blob/7b1f6c173d17b3bf30e45426f6df39473c6a1163/lib/commands/view.js#L189-L196
note: calling npm info pkg-a is like npm info pkg-a@latest, so even if that returns no matches, it still shouldn't return E404
Am I missing something? How have you observed this?
There was a problem hiding this comment.
No, you're right, I goofed.
Had been testing against some actual versions when debuggin, and made an incorrect assumption, sorry about that.
Just pushed a commit that removes this code and the related test, makes the PR quite a bit simpler, thanks for the feedback!
Andarist
changed the title
15cf592
…24) ## Summary - Root cause of today's recurring Release failures ("You cannot publish over the previously published versions: 1.0.5"): npm 12 (installed by the Release job's OIDC npm-upgrade step) changed `npm info --json` to wrap its output in an array. `@changesets/cli@2.31.0`'s `getPackageInfo()` reads `pkgInfo.versions` off the unwrapped result, so under npm 12 it's always `undefined`, and `changeset publish` concludes every already-published package is unpublished, then re-attempts publishing it. npm correctly rejects the duplicate, and Release goes red. - This is a genuine upstream defect, not a misuse on our side: confirmed via `changesets/changesets#2164` (closed), matching our exact symptom and environment (npm 12.0.1, `@changesets/cli@2.31.0`, GitHub Actions). Fixed by `changesets/changesets#2159`, released in `@changesets/cli@2.31.1`. - Bumped the lockfile to `2.31.1` (already permitted by the existing `^2.31.0` range in package.json, no manifest change needed). Verified the array-unwrap fix (`Array.isArray(parsed) ? parsed[0] : parsed`) is present in the installed source. ## Why this wasn't caught by the earlier fixes today - #21 (removing the release job's npm cache) and #22 (the audit-fix PR) both happened to pass Release, but for unrelated reasons: #22's run took `changesets/action`'s "open a Version Packages PR" path (since it carried a pending changeset) rather than the "attempt to publish" path that triggers this bug. The defect was still live underneath. ## Verification - `run-checks.sh`: 4 passed, 0 failed, 0 skipped (typecheck, lint, format, test). ## Sequencing This should merge **before** #23 (the pending Version Packages PR), so the eventual patch-release publish run uses the fixed `@changesets/cli`, and so ordinary future pushes to main don't hit this bug again.
Fixes the failing Release workflow on main: npm 12 (now npm@latest in the shared changesets workflow) wraps successful `npm info --json` output in an array, which made changeset publish treat 9.4.0 as unpublished and fail attempting to republish it. Fixed upstream in changesets/changesets#2159 (released in 2.31.1).
3 participants
In npm v12
npm view/npm infoalways return an array.This causes changesets to incorrectly interpret the packages as not published, and attempt to publish them, causing errors from the registry.
e.g.
This PR fixes this by detecting if the output is an array, and grabbing the last element if it is. This should keep compatibility with v11 and v12 behaviour.
The "error" state is also changed, so it now detects if empty string and E404.