Skip to content

npm ci fails intermittently due to missing lockfile shadow entries - #1143

Closed
alexmontesg wants to merge 3 commits into
mainfrom
fix/GH-1142-npm-ci-lockfile
Closed

npm ci fails intermittently due to missing lockfile shadow entries#1143
alexmontesg wants to merge 3 commits into
mainfrom
fix/GH-1142-npm-ci-lockfile

Conversation

@alexmontesg

Copy link
Copy Markdown
Contributor

Closes #1142

What

  • Restores two nested lockfile shadow entries (@emnapi/core@1.11.2, @emnapi/runtime@1.11.2) required to satisfy @oxc-resolver/binding-wasm32-wasi's exact pins. Pure addition, verified with npm ci.
  • Hardens version:development (release script) to stop using a plain npm install, which is what silently dropped these entries in the first place (commit adfbb4c).
  • Adds an npm ci --dry-run" guard step to the release workflow so any future lockfile regression fails the release job loudly instead of landing on main` unnoticed.

Verification

  • npm ci succeeds cleanly on this branch (previously failed with Missing: @emnapi/core@1.11.2 from lock file).
  • JSON/YAML validated, lint passes.

npm ci intermittently fails with 'Missing: @emnapi/core@1.11.2 from
lock file' because @oxc-resolver/binding-wasm32-wasi pins an exact
@emnapi/core@1.11.2 and @emnapi/runtime@1.11.2, but no nested shadow
entry existed to satisfy it (top-level @emnapi/* resolves to 1.4.5
for unrelated packages). These entries were dropped by an automated
release commit (adfbb4c) and never restored.

Restored verbatim from the last known-good lockfile (ce6c215).
Pure addition, no other resolved versions changed.

Also hardens the release script that caused the original regression:
version:development previously ended with a plain 'npm install',
which is free to re-resolve and rewrite the lockfile tree. It now
runs 'npm ci' first to validate the existing tree, then constrains
the version-bump write to 'npm install --package-lock-only'. A new
'npm ci --dry-run' guard step in the release workflow fails the
release job loudly if a future regeneration breaks the lockfile
again, instead of silently pushing a broken lockfile to main.

Closes #1142
@alexmontesg
alexmontesg requested a review from jesusmpc August 4, 2026 09:14
Node 24.11.1 (pinned in code/.tool-versions) already bundles npm
11.6.2, satisfying the >=11.5.1 requirement for trusted publishing.
Self-upgrading npm via 'npm install -g npm@^11.5.1' introduced an
untracked npm version drift, which is what silently dropped lockfile
shadow entries in commit adfbb4c. Removed the guard step added
earlier for the same reason; no longer needed once the release job
consistently uses the asdf-managed npm.
@jesusmpc jesusmpc added the skip-release Skips the release creation label Aug 4, 2026
…pment

adfbb4c (the commit that dropped the @emnapi shadow entries) was
produced by the 'Release / Commit and Tag' step, which runs
version:release — not version:development (that only runs later, for
the next-development-iteration commit). Move the npm ci-then-install
guard to the script that actually caused the regression.
@sonarqubecloud

sonarqubecloud Bot commented Aug 4, 2026

Copy link
Copy Markdown

@alexmontesg

Copy link
Copy Markdown
Contributor Author

Closing this issue, we found a documented issue on nx: nx release: please update your lock file with npm install before continuing. We will be skiping a resolution for now. A possible fix would be to clean install everything on the release job (rm -rf node_modules && rm package-lock.json && npm install)

@alexmontesg alexmontesg closed this Aug 4, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

skip-release Skips the release creation

Projects

None yet

Development

Successfully merging this pull request may close these issues.

npm ci fails intermittently due to missing lockfile shadow entries for @emnapi packages

2 participants