fix(ci): regenerate the npm wrapper lock with CI's npm major - #234
Open
Mikola Lysenko (mikolalysenko) wants to merge 2 commits into
Open
fix(ci): regenerate the npm wrapper lock with CI's npm major#234Mikola Lysenko (mikolalysenko) wants to merge 2 commits into
Mikola Lysenko (mikolalysenko) wants to merge 2 commits into
Conversation
release-readiness regenerates the lock with the runner's npm 10, which does not write the `libc` platform arrays npm >= 11 emits — so the npm-11-shaped lock from #233 makes 'version-sync.sh 4.0.0 is not a no-op' fail on every PR and on main. The check's npm is the effective canon; note the npm-major dependence for whoever next refreshes the lock locally. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
The release-readiness gate re-runs version-sync.sh and compares the regenerated npm/socket-patch/package-lock.json byte-for-byte, so the lock's canonical shape is defined by whatever npm regenerates it. npm 11 adds libc arrays that npm 10 omits, which is how the #233 refresh (made locally with npm 11) broke the gate under CI's npm 10 — and the same drift would recur in reverse the day the runner image jumps to npm 11. Pinning the refresh via npx makes the gate independent of both the runner default and the developer's local npm; bumping the pin now takes a deliberate commit that refreshes the lock alongside it. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
release-readinessis red on main (and on every PR): theversion-sync.sh 4.0.0 is not a no-opgate fails onnpm/socket-patch/package-lock.json.Root cause: the lock refresh in #233 was generated with npm ≥ 11, which writes
libcplatform arrays on the optional platform-package entries. The CI runner's npm 10 does not emit that field, sonpm install --package-lock-onlyinsideversion-sync.shstrips 24 lines and the no-op check fails — on main itself, independent of any PR content.This regenerates the lock with CI's npm major (
npx npm@10 install --package-lock-only --ignore-scripts), making the gate a no-op again. Verified locally: with this lock, npm 10 regeneration is byte-stable.Follow-up included (731d322):
version-sync.shnow runs the lock refresh throughnpx --yes npm@10, so the gate's canon no longer depends on the runner default or the developer's local npm. Without the pin, anyone refreshing the lock with npm ≥ 11 would re-introduce thelibcfields (verified: npm 11.16 fresh-resolve writes 8 of them; npm 10 writes none and reproduces this PR's lock byte-for-byte), and the gate would flip in reverse the day the runner image jumps to npm 11. Bumping the pin is now a deliberate commit that refreshes the lock alongside it.Not addressed here (separate, also main-wide):
hosted-e2efails because production no longer publishes a free patch forpkg:cargo/traitobject@0.1.1(the suite's pinned cargo leg; the public proxy now returnsnot_foundfor it). Fixing that needs a catalog decision — republish the patch, or pick a replacement pinned package per the suite's own guidance.🤖 Generated with Claude Code
Note
Low Risk
Lockfile-only change with no application code; risk is limited to install/resolution metadata consistency across npm versions.
Overview
Regenerates
npm/socket-patch/package-lock.jsonso it matches what CI’s npm 10 writes whenversion-sync.shrunsnpm install --package-lock-only.The diff removes the optional
libcarrays (glibc/musl) from the Linux@socketsecurity/socket-patch-*platform entries. Those fields appear when the lock is refreshed with npm ≥ 11; npm 10 omits them, so the release-readiness version-sync no-op check was failing even on unrelated changes.No runtime or package logic changes—only lockfile metadata so the gate stays byte-stable on the runner.
Reviewed by Cursor Bugbot for commit 640a0a5. Configure here.