fix(prune): Relocate stranded transitive deps when promoting npm workspace-nested packages

[anthonyshew]

Description

Fixes #13109.

turbo prune --docker produced a structurally invalid package-lock.json when a workspace-nested package gets promoted to root during pruning.

When the previously-hoisted version of a package (e.g. send@1.2.1, needed only by a now-pruned workspace) is dropped, turbo correctly promotes the workspace-nested send@0.17.2 to node_modules/send — but its transitive deps that lived as siblings under apps/app-2/node_modules/ (e.g. mime@1.6.0) were left stranded. Node's resolution only walks upward, so the promoted node_modules/send@0.17.2 could no longer reach apps/app-2/node_modules/mime@1.6.0, and npm ci from the pruned lockfile crashes at runtime with Cannot find module.

The fix

crates/turborepo-lockfiles/src/npm.rs: after a package is promoted during rehoisting, relocate_stranded_closure walks the promoted package's dependency closure, using the original lockfile as the source of truth for which version each dependency must resolve to. For any dependency that no longer resolves correctly from the new position, it copies the correct version (and its subtree) to a reachable spot:

• hoist to the root slot (node_modules/<dep>) when it's free, or
• nest directly under the promoted package (node_modules/send/node_modules/<dep>) when the root slot is still occupied by an incompatible version (here mime@3.0.0, kept because it's a root devDependency).

Recursion is guarded by a visited-set, and now-unreachable stranded copies are removed.

Regression test fixture + validation gap

This change adds the issue-13109 npm fixture (a real lockfile generated with npm@11.7.0 that reproduces the exact hoisting from the issue).

While adding it I found that the lockfile-tests harness's npm ci --dry-run check does not catch this bug — it mirrors the lockfile's tree verbatim and never verifies that each package can actually resolve its declared deps. So I added an opt-in validateResolution meta flag that additionally runs npm ls --package-lock-only --all, which fails with ELSPROBLEMS on stranded deps (and works fully offline). It's opt-in because npm ls --all is too strict to enable globally — it flags benign peer-dependency / missing-@types conditions that npm ci --dry-run tolerates in a couple of existing fixtures.

Testing

• New Rust unit test test_subgraph_relocates_stranded_promoted_deps; all 194 turborepo-lockfiles tests pass, clippy clean.
• Built turbo before/after the fix: pre-fix output strands apps/app-2/node_modules/mime; post-fix relocates it to node_modules/send/node_modules/mime, and npm ls reports a clean tree.
• The check-lockfiles harness fails on a pre-fix binary and passes on the fixed binary for issue-13109, making it a genuine regression guard. All 34 npm fixtures still pass.

Note: the issue's idealized "expected" output wanted node_modules/mime → 1.6.0, but since the pruned root keeps its mime@^3.0.0 devDependency, the correct result is mime@3.0.0 at root with mime@1.6.0 nested under send — which is what the fix produces and what npm ci / npm ls validate as correct.

🤖 Generated with Claude Code

---

Generated by Claude Code

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
examples-basic-web	Ready	Preview, Comment, Open in v0	Jun 18, 2026 12:26pm
examples-designsystem-docs	Ready	Preview, Comment, Open in v0	Jun 18, 2026 12:26pm
examples-gatsby-web	Ready	Preview, Comment, Open in v0	Jun 18, 2026 12:26pm
examples-kitchensink-blog	Ready	Preview, Comment, Open in v0	Jun 18, 2026 12:26pm
examples-nonmonorepo	Ready	Preview, Comment, Open in v0	Jun 18, 2026 12:26pm
examples-svelte-web	Ready	Preview, Comment, Open in v0	Jun 18, 2026 12:26pm
examples-tailwind-web	Ready	Preview, Comment, Open in v0	Jun 18, 2026 12:26pm
examples-vite-web	Ready	Preview, Comment, Open in v0	Jun 18, 2026 12:26pm
turbo-site	Ready	Preview, Comment, Open in v0	Jun 18, 2026 12:26pm