fix(ci): regenerate the npm wrapper lock with CI's npm major - #234
Open
Mikola Lysenko (mikolalysenko) wants to merge 1 commit into
Open
fix(ci): regenerate the npm wrapper lock with CI's npm major#234Mikola Lysenko (mikolalysenko) wants to merge 1 commit into
Mikola Lysenko (mikolalysenko) wants to merge 1 commit 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>
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.Caveat for the next lock refresh: the check's npm (the runner default) is the effective canon. Anyone refreshing the lock locally with npm ≥ 11 will re-introduce the
libcfields and re-break the gate — worth either pinning node/npm in therelease-readinessjob or inversion-sync.shat some point.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.