aube add re-resolves unrelated versions in a fresh npm package-lock.json

[mwolson]

• Repo: https://github.com/mwolson/tmp-aube-issues
• Case: npm-lock-add-reresolve
• aube: 1.38.1 linux-x64 (2026-08-10)
• Lockfile produced by: npm 11.17.0 install --ignore-scripts --package-lock-only --no-audit --no-fund
• Same lock accepted byte-identical by npm 12.0.2

aube install treats a fresh npm package-lock.json as up to date. aube add of a named spec then re-resolves unrelated hoisted versions in that lock. Real npm only edits the named spec.

This is not the missing-entry repair in #690 npm-lock-missing-entry, the stale-lock-treated-fresh case in #964 lock-drift-fresh, or the optional-native recording in #938 npm-lock-optionals. After #1155 filter-add-optionals, the expected add lock diff was only the new package and its dependency.

Reproduction

git clone https://github.com/mwolson/tmp-aube-issues.git
cd tmp-aube-issues/npm-lock-add-reresolve
# Point NPM_BIN at a real npm if PATH npm is aubeshim.
./repro.sh

The script exits 1 while the issue is present.

Manual form of the same check:

cd npm-lock-add-reresolve

# Fresh: aube install leaves the lock's hoisted camelcase at 5.3.1.
aube install --ignore-scripts --reporter append-only

# Control: real npm only promotes the already-transitive is-number.
npm install is-number@7.0.0 --ignore-scripts --package-lock-only --no-audit --no-fund
# packages["node_modules/camelcase"].version is still 5.3.1

# Subject: aube add re-hoists camelcase.
aube add is-number@7.0.0 --ignore-scripts --reporter append-only
# packages["node_modules/camelcase"].version becomes 6.3.0

package.json pins jest-config at exact 29.7.0, matching the lock. npm hoists camelcase@5.3.1 (@istanbuljs/load-nyc-config wants ^5.3.1) and nests camelcase@6.3.0 under jest-validate (^6.2.0). is-number@7.0.0 is already a transitive.

The same 5.3.1 -> 6.3.0 hoist happens for:

• aube add jest-config@29.7.0 (already the exact pin; manifest stays 29.7.0)
• aube install --fix-lockfile (no named package)
• isolated or hoisted AUBE_NODE_LINKER

--prefer-frozen-lockfile on add does not prevent it.

Smaller public trees did not reproduce the unrelated hoist: express@4.18.2, esbuild@0.25.12 (that case only strips optional: true from platform packages), and a two-package @istanbuljs/load-nyc-config@1.1.0 + jest-validate@29.7.0 pair.

Expected

aube add is-number@7.0.0 updates the is-number spec and keeps already-locked versions that still satisfy their ranges, the same way real npm install is-number@7.0.0 does. aube install --fix-lockfile should not rewrite a lock that aube install already treats as fresh.

Actual

aube add re-resolves the hoisted camelcase from 5.3.1 to 6.3.0. On a larger npm-accepted Expo lock the same path dropped optional and peer entries and changed dozens of unrelated top-level versions, including some that moved backwards.

Docs

https://aube.jdx.dev/package-manager/install.html (prefer-frozen reuses a fresh lock; --fix-lockfile repairs drifted entries)

https://aube.jdx.dev/package-manager/lockfiles.html

https://aube.jdx.dev/package-manager/dependencies.html

[jdx]

Confirmed and fixed in #1287.

The resolver retained both camelcase versions; the churn happened when the npm writer rebuilt the physical hoist/nest layout from the flat graph. Its BFS encountered jest-validate -> camelcase@6.3.0 first and replaced npm’s existing top-level camelcase@5.3.1 choice.

The fix seeds the writer with still-reachable top-level placements from the existing npm lockfile, while pruning a preference after its last dependency edge disappears. I verified both the supplied npm-lock-add-reresolve/repro.sh and aube install --fix-lockfile against the rebuilt CLI.

Thanks for the precise reproduction.

AI-assisted — Tool: Codex; model: openai/gpt-5; version: unavailable.

[mwolson]

Confirmed fixed with aube 1.41.0 using npm-lock-add-reresolve. ./repro.sh now passes: aube add is-number@7.0.0 preserves npm's top-level camelcase@5.3.1 choice instead of promoting 6.3.0. The fix shipped in #1287 preserve-npm-hoist-choices. Thanks!