InditexTech / InditexTech/weavejs
npm ci fails intermittently due to missing lockfile shadow entries for @emnapi packages
- Dominant language
- TypeScript
- Stars
- 200
- Forks
- 18
- Avg merge
- 8h
- Merged PRs (30d)
- 13
Description
## Description
`npm ci` intermittently fails with:
```
npm error Missing: @emnapi/core@1.11.2 from lock file
npm error Missing: @emnapi/runtime@1.11.2 from lock file
```
## Root cause
`@oxc-resolver/binding-wasm32-wasi` (an optional, wasm32-only dependency of the oxc/rolldown toolchain, never installed on linux-x64 CI runners) pins exact versions `@emnapi/core@1.11.2` / `@emnapi/runtime@1.11.2`. The top-level `@emnapi/*` packages resolve to `1.4.5` for unrelated consumers, so a nested lockfile shadow entry is required to satisfy the exact pin. That shadow entry existed as of commit `ce6c215b` and was silently dropped by the automated release commit `adfbb4c6` ("chore: Update CHANGELOG with 5.1.5 version").
The failure is intermittent (not purely deterministic from lockfile content alone — see investigation notes) because npm's optional/platform-conditional dependency validation in `npm ci` appears to have run-to-run variance for this exact package shape.
## Contributing factor
The release workflow's `version:development` npm script (in `code/package.json`) ends with a plain `npm install` (not `npm ci`), which is free to re-resolve and rewrite the lockfile tree — this is how the shadow entries were dropped in the first place, and the same risk remains today for future releases.
## Proposed fix
1. Restore the two missing nested shadow entries in `code/package-lock.json` (pure addition, verified working via `npm ci`).
2. Harden `version:development` to avoid uncontrolled lockfile rewrites, e.g. run `npm ci` before `npm install --package-lock-only`, and/or add an `npm ci --dry-run" guard step in the release workflow right after the version bump, so a broken lockfile fails the release job loudly instead of being pushed to `main` silently.
Contributor guide
Research direction
Start with code/package-lock.json and code/package.json, then inspect the release workflow and the version:development script. Run npm ci to reproduce or verify the lockfile issue; done means the @emnapi shadow entries are restored and the release process no longer silently rewrites or publishes an invalid lockfile.
Written by the indexing model from the issue text.
Assessment
- Domain
- build-system, release
- Issue type
- Bug
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 68/100