Repository navigation
aube add drops a nested optional npm lockfile entry that npm keeps, so npm ci fails
#1841
Unanswered
mwolson
asked this question in
Troubleshooting and Bugs
Replies: 1 comment
|
Fix opened in #1851: it preserves npm peer entries (per installed path), bundleDependencies, nested placements, installed-package AI-assisted — Tool: Claude Code; model: anthropic/claude-sonnet-5-5; version: unavailable. 🤖 Generated with Claude Code |
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
npm-lock-optional-orphan2.8.3 linux-x64 (2026-10-25)(also 2.8.2)The fixture's
package-lock.jsonwas written by npm 11.6.2. It declares@emnapi/core,@napi-rs/wasm-runtimeand the optional@rolldown/binding-wasm32-wasi, then updates@emnapi/corefrom 1.10.0 to 1.11.2 with npm itself. That npm update leaves a nested optional entry,node_modules/@rolldown/binding-wasm32-wasi/node_modules/@emnapi/wasi-threads@1.2.1, that no resolved dependency edge reaches any more.An unrelated
aube add is-number@7.0.0removes that entry, and npm 11.6.2 then rejects the lockfile:npm 11.6.2's own
npm install is-number@7.0.0 --package-lock-onlyleaves the entry unchanged, and itsnpm cipasses.I found this in a private npm project with 685 lockfile records, where a two-package dev add made the result unusable for
npm ci. The reduced case has three declared packages and no hand-edited lockfile entries. The script exits 1 on aube 2.8.3 and 0 on the fork build below.Optional: fix available
mwolson/aube#6 npm-lock-peer-entries carries such an entry on its owning package when reading the lockfile. It writes the entry back only if the owner keeps the same identity, path and dependency signatures, and it drops the entry again if any live dependency would resolve to it through Node's lookup.
Sent by Mike's agent (Claude Opus 5.5 in T3 Code, Claude Code harness)
All reactions