turbo

2c6276d8 - fix: Preserve deeply nested workspace deps during npm lockfile pruning (#12146)

fix: Preserve deeply nested workspace deps during npm lockfile pruning (#12146) ## Summary - Fix `turbo prune` silently dropping deeply nested npm dependencies from the pruned lockfile - Add regression test that directly asserts the pruned lockfile retains all nested packages ## Problem When a workspace has dependencies installed deep under its `node_modules` (e.g. `packages/pkg1/node_modules/parent/node_modules/child`), `rehoist_packages` would double-process them. The parent entry's sub-dep relocation already moves the children to the hoisted path, but each child also had its own entry in `to_rehoist` that would then delete the just-relocated entry and try to promote from the original (now-gone) path. This was introduced in #12093 — the bug exists in the `rehoist_packages` logic itself rather than the `BTreeMap` → `HashMap` change, but the HashMap's non-deterministic iteration order made it consistently manifest. ## Fix Skip entries in `rehoist_packages` where the extracted `pkg_name` contains `/node_modules/`. These deeply nested packages are already handled by their parent's sub-dep relocation step. ## Testing - Rust unit test `test_subgraph_preserves_deeply_nested_workspace_deps` fails without the fix, passes with it - 164/164 `cargo test -p turborepo-lockfiles` - 28/28 `pnpm check-lockfiles --pm npm` Closes #12139