{{ message }}
Repository navigation
ci: Build on Node 24 and guard @next/swc libc fields - #28
Merged
Merged
Conversation
Next 16.2.10 started publishing libc metadata on the @next/swc-linux-*-gnu/musl packages, so a lockfile regeneration with npm < 11.11.0 can now strip those fields exactly like the @rolldown/binding and lightningcss ones the guard already covers - and a partial regeneration could drop only the SWC fields while the guarded entries survive, letting Linux installs pull both glibc and musl SWC binaries with CI still green. Extend the entry pattern to the @next/swc family and move it out of the comment's list of natives that legitimately lack libc. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_0161H2KBxRHmcGr3QEckXtF8
Contributor
Dependabot regenerates the lockfile with npm 11.17.0, which writes the npm 11 shape: libc fields preserved (npm >= 11.11.0) and unsatisfied optional-peer entries pruned (npm >= 11.5.0). npm 10 - bundled with Node 22 and never updated past it; Node 20 reached EOL still on npm 10 - rejects that shape, failing npm ci with "Missing: conventional-commits-parser@6.4.0 from lock file" on every Dependabot PR (currently #26). Node 24 is Active LTS, bundles npm 11.16.0, and is also what the Vercel project builds and runs on, so CI stops testing a different runtime than production. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_0161H2KBxRHmcGr3QEckXtF8
shahirtaj
marked this pull request as ready for review
July 12, 2026 23:40
This was referenced Jul 12, 2026
This branch was successfully deployed
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
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.

What
Two lockfile-drift hardening changes:
npm ciruns an npm >= 11.11.0 toolchain.package-lock.test.tslibc guard now covers@next/swc-linux-*-gnu/musl, which started publishinglibcmetadata with Next 16.2.10 (merged in chore(deps-dev): Fix lockfile sync for the minor-and-patch group bump #27).Why
The Node bump fixes the recurring dependabot CI failures (#25 before, #26 right now). Dependabot regenerates the lockfile with npm 11.17.0, which writes the npm 11 shape:
libcfields preserved (fixed in npm 11.11.0, npm/cli#9025) and unsatisfied optional-peer entries pruned (npm 11.5.0, npm/cli#8431). npm 10 - bundled with Node 22 and never updated past it (Node 20 reached EOL still on npm 10) - rejects that shape, failing every dependabot PR withMissing: conventional-commits-parser@6.4.0 from lock file. Node 24 is Active LTS, bundles npm 11.16.0, and is also what this project's Vercel builds run on (Node 24 has been Vercel's default for new projects since Nov 2025), so CI stops testing a different runtime than production. The hand-added optional-peer entry from #27 becomes unnecessary and will disappear naturally on the next dependabot regeneration - npm 11 accepts the lockfile either way.The guard extension closes a blind spot: a partial regeneration or bad conflict resolution could drop only the new SWC
libcfields while the guarded@rolldown/binding/lightningcssentries survive - CI would stay green while Linuxnpm cipulls both the glibc and musl SWC binaries.@unrs,@img/sharp, and@tailwindcss/oxidestill publish nolibc, so they stay excluded, as does the-gnueabihfbuild.Verification
npx vitest run package-lock.test.ts- 15 tests passing (was 12; the 4@next/swcentries are now asserted against the correct glibc/musl values)npm run typecheck,npm run lint,npx prettier --check .- cleanFollow-up
Once this merges, #26 needs a
·@·d·ependabot r·ebase(or a CI re-run) to go green - its lockfile is already npm-11-shaped and correct; only CI's npm 10 was rejecting it.🤖 Generated with Claude Code
https://claude.ai/code/session_0161H2KBxRHmcGr3QEckXtF8