chore: Fix release github action breaking package-lock.json#5435
Merged
Conversation
agusayerza
commented
Feb 11, 2026
| echo(chalk.grey(` ${figures.tick} Bumped root package version in ${rootPackageJson}`)); | ||
| } | ||
| } | ||
|
|
||
| async function bumpReference(packageName) { | ||
| const packagesJson = await glob('packages/*/package.json'); | ||
| // We don't use npm install, because it behaves incoherently with workspaces and different terminals |
Contributor
Author
There was a problem hiding this comment.
Funny you say so... 😆
1228442 to
6b31f4f
Compare
TBonnin
approved these changes
Feb 11, 2026
Collaborator
TBonnin
left a comment
There was a problem hiding this comment.
Thank you for doing this.
Can we add a comment section on top of the bump functions to clarify why we don't do npm install/version with link to npm issue tracker and details about the issue, so we remember in 6months when one of us want to bring back npm install
| async function bumpLockfileVersions() { | ||
| await spinner('update package-lock versions', async () => { | ||
| const lockfilePath = 'package-lock.json'; | ||
| const lock = JSON.parse((await fs.readFile(lockfilePath)).toString()); |
Collaborator
There was a problem hiding this comment.
maybe a try/catch in case the file is actually broken
| async function bumpWorkspacePackageVersion(packageName) { | ||
| const packagesJson = await glob('packages/*/package.json'); | ||
| for (const packageJson of packagesJson) { | ||
| const content = JSON.parse((await fs.readFile(packageJson)).toString()); |
Collaborator
There was a problem hiding this comment.
maybe try/catch if file is corrupted and parsing fails
7396947 to
14907eb
Compare
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.
Root cause
The release workflow (
publish.yaml) runs onubuntu-latest(Linux x64). The oldpublish.mjscallednpm i8 times during the publish sequence (once after each package publish). On Linux, npm strips platform-specific optional dependencies (e.g.lightningcss-darwin-arm64,lightningcss-win32-x64-msvc, etc.) frompackage-lock.jsonbecause they fail theEBADPLATFORMcheck. Thengitrelease.mjscommits this corrupted lockfile to master.This is a long-standing npm bug: npm/cli#4828 (opened April 2022) and npm/cli#7961 (regression in npm 10.3.0+).
A fix was merged in npm/cli#8184 and shipped in npm 11.3.0 (April 2025), but it does not fully resolve the issue. Users continue to report the bug on npm 11.5.2, 11.6.0, and later. Our release that broke (bca40e6d, v0.69.31) was already using npm 11.5.1. There is no flag (
--include=optional,--package-lock-only,--ignore-scripts, etc.) that prevents the pruning.I have tested the logic on this PR to verify it works on dryruns. We will need to verify the actual fix once this is merged on master.
Fix
Replace all
npm iandnpm versioncalls inpublish.mjswith direct JSON file manipulation:bumpWorkspacePackageVersion()— writes version directly topackages/*/package.jsonbumpReference()— updates cross-workspace dependency references inpackage.jsonfilesbumpRootVersion()— writes version to rootpackage.jsonbumpLockfileVersions()— updates version entries inpackage-lock.jsonfor all published packagesnpm never modifies the lockfile during the release, so platform-specific optional dependencies are preserved.
Ghost packages cleanup
Found 5 extraneous registry-resolved entries in
package-lock.jsonfor workspace packages (@nangohq/types,@nangohq/node,@nangohq/providers). These were nested underpackages/cli/node_modules/andpackages/webapp/node_modules/with"extraneous": true.These are artifacts from the old publish flow: the old script would publish a package to npm, then run
npm i— npm would pull the just-published version from the registry and nest it inside other workspace packages instead of using the workspace link. Each release accumulated more of these ghost entries.Since we no longer call
npm iduring publish, these entries won't be recreated. They've been removed from the lockfile.The change also introduces a curated publishedPackageNames set so every workspace package receives deterministic JSON-based version rewrites without depending on npm install/version.
Possible Issues
•
bumpLockfileVersionsonly rewrites dependency values that match the strictversionRegex, so caret/range specifiers or git refs will not be updated and may drift.• Any workspace omitted from
publishedPackageNameswill never receive version updates in the lockfile, potentially causing publish inconsistencies.• Concurrent release runs could race because package versions are written before
npm publish; a second run might see already-bumped versions and behave unpredictably.This summary was automatically generated by @propel-code-bot