0.7.4: install re-resolves the whole dependency graph instead of only what changed

[candrewlee14]

What happens

After a small manifest edit, nub install on 0.7.4 re-resolves every ranged dependency to the newest version in range, instead of keeping the versions already in the lockfile. 0.6.0 only updates what the edit touched.

Same repo, same three-line change to a pnpm-workspace.yaml catalog (three specs, each to an equivalent range so nothing needed to move):

	changed lines in pnpm-lock.yaml
0.7.4	14,492 (2,456 version changes)
0.6.0	6 (just the three spec strings)

It also happens with no manifest edit at all. nub install --no-frozen-lockfile on an unchanged manifest moved unrelated packages, for example @types/pg 8.20.0 to 8.20.4.

Where it seems to come from

Probably the vendored engine rather than nub itself. Standalone aube 1.38.0 does the same thing on the same repo; nub 0.6.0 does not. 0.7.0 synced the engine to upstream 1.35.0.

Why it hurt

A one-line dependency change became a 14k-line lockfile diff. The version movement was enough to break type checking in our workspace, so a routine change turned into a debugging session. It also broke a release: the same behaviour reached a lockfile merge driver we have configured as nub install --lockfile-only, and a rebase produced a lockfile pinning an older version of a package than the manifest asked for, while reporting success.

For now we make the manifest edit, generate the lockfile with 0.6.0, and verify with nub ci on 0.7.4, which accepts the result.

Note

--frozen-lockfile and the default --prefer-frozen-lockfile disagree about the same lockfile: frozen treats it as current, while the default decides it is stale and re-resolves everything. That looked like the most useful thread to pull on.

[pullfrog]

Reproduced, on 0.7.4 and on the current 0.7.5. It is a nub-side regression added in the 0.7.0 line, and the trigger is minimumReleaseAge, not the catalog edit.

Repro

Fixture: four ranged deps, lockfile generated so each sits below the newest version in range. No manifest edit at any point.

step	@types/pg	chalk	debug	semver
nub@0.6.0 install	8.20.0	5.3.0	4.3.0	7.5.0
nub@0.7.4 install	8.21.0	5.6.2	4.4.3	7.8.5
nub@0.7.4 install --frozen-lockfile	8.20.0	5.3.0	4.3.0	7.5.0

Every ranged dependency moved on the second run. Latest (0.7.5) behaves the same as 0.7.4.

Mechanism

Install sets revalidate_release_policy unconditionally (crates/nub-cli/src/pm_engine/install_family.rs:1204). When the install-shape settings hash differs from the last run and minimumReleaseAge > 0 — the default is 1440 — two things happen:

1. commands/install/resolve.rs:568 — prefer-frozen stops trusting the lockfile and falls through to a full resolve.
2. commands/install/mod.rs:1102 — existing_for_resolver is set to None, so the resolver gets no locked-version hints and picks the newest allowed version for every range.

Step 2 is what turns "revalidate the picks against the age gate" into "re-resolve the world". Passing --frozen-lockfile skips both, which is the disagreement you spotted.

Evidence for each link:

• RUST_LOG=debug on the drifting run prints install warm path miss: install settings or the active Node version have changed, then active release-age policy requires lockfile-pick revalidation; re-resolving....
• Setting minimumReleaseAge=0 makes the same 0.6.0 → 0.7.4 upgrade preserve every version.
• The same binary run twice with identical flags is stable; changing one install-shape flag (nub install, then nub install --node-linker=hoisted) reproduces it in full on 0.7.5 alone.
• The revalidate_release_policy opt-in is absent at v0.6.0 and present at v0.7.0, matching your bisect.

So the everyday trigger is any settings change: upgrading nub across a version that moves a default (0.6.0 → 0.7.x moves the linker default), editing .npmrc / nub.jsonc / pnpm-workspace.yaml, or passing a different install flag. The catalog edit is incidental — it is the settings drift from the version bump that fired, not the catalog.

A second, independent divergence

Running nub install --no-frozen-lockfile re-resolves from scratch on every version, 0.6.0 included. On the same fixture nub moves all four deps; pnpm 10 leaves the lockfile byte-identical, because pnpm still prefers locked versions when only the lockfile-freshness requirement is relaxed. That is deliberate today (commands/install/mod.rs:1061), and it is why the fallback above is so destructive: outside --fix-lockfile there is no "re-resolve but keep unchanged picks" path for the prefer-frozen fallback to land in.

One item needs more information

The merge-driver case — a lockfile "pinning an older version of a package than the manifest asked for, while reporting success" — is an out-of-range pick, which neither finding above explains. If you can name the package and the spec it was resolved against, that is worth its own issue.

Workaround

Setting minimumReleaseAge=0 avoids it but gives up the publish-age gate. Generating with --frozen-lockfile where the lockfile is already correct is the narrower option, and matches what you are doing with nub ci today.

  ^{｜ View workflow run ｜ via Pullfrog ｜ Using Claude Opus ｜ 𝕏}

[candrewlee14]

Tracked it down, for the nub install path at least.

nub install asks the engine to re-check the minimumReleaseAge gate against the versions already locked. The engine decides whether that check is needed by comparing settings_hash, which includes the raw pnpm-workspace.yaml bytes — where catalog lives. So a catalog edit looks like a gate change, and the check is done by resolving as if there were no lockfile. That's the re-pick.

Same reason frozen and prefer-frozen disagreed: ci.rs turns the check off.

Fix in #710 — compare a hash of just the age settings. A locked version only gets older, so if the gate didn't move, what passed before still passes.

One loose end: I reported standalone aube 1.38.0 doing this too, but it leaves this off by default. If that was right, there's a second cause #710 doesn't cover.