@nathanwhit you're right — I confirmed empirically that pnpm produces only one copy of @nestjs/[email protected] for the exact same package set (same lockfile-pinned @nestjs/{common,core,platform-express}@10.4.5 + @nestjs/[email protected] + reflect-metadata@^0.2), while deno install produces five (@[email protected] through @[email protected]_4). So this is an npm peer-dep resolution bug — these copies should have been deduplicated. I've reverted the install-time change (it was papering over the symptom, as you said).

Repro with pnpm 9.15.0:

$ pnpm install
$ ls node_modules/.pnpm | grep '@nestjs+core'
@[email protected]_@[email protected][email protected][email protected]__@nestjs+platform_v2fuvjwzi6rez7k3z2o4qmdrhy
$ readlink node_modules/@nestjs/core
../.pnpm/@[email protected]_..._v2fuvjwzi6rez7k3z2o4qmdrhy/node_modules/@nestjs/core
$ readlink node_modules/.pnpm/@nestjs+terminus*/node_modules/@nestjs/core
../../../@[email protected]_..._v2fuvjwzi6rez7k3z2o4qmdrhy/node_modules/@nestjs/core

Both the user-visible node_modules/@nestjs/core and @nestjs/terminus's nested @nestjs/core resolve through the same .pnpm entry → same realpath → same Module._cache entry → same ModuleRef class → NestJS DI succeeds.

For Deno, the existing dedup_peer_dependents pass in libs/npm/resolution/graph.rs is supposed to merge equivalent variants but doesn't fire here. The five @nestjs/[email protected] variants share the same nv and the same effective set of dep + peer-dep NVs (@nestjs/[email protected], @nestjs/[email protected], [email protected], [email protected]); each variant's nested NpmPackageId.peer_dependencies only differs in cycle-unrolling depth. is_superset_node compares children by name+nv and peer-deps by nv (not by NodeId), so the variants should be mutual subsets/supersets — but the pass leaves all five behind.

I'd appreciate guidance on whether the fix belongs in dedup_peer_dependents (extending it to handle the mutual-superset cycle case) or upstream in resolve_peers_of_node (not creating the spurious copies in the first place). Happy to take a swing once direction is clear.

it should probably avoid producing the duplicates (resolve_peers_of_node), though if that is intractable i think a fix in dedup_peer_dependents could work (it would need to be careful to only dedupe valid sets). i would suggest referencing pnpm's source code to see how they handle this.

@nathanwhit reworked along your guidance.

Investigation:

• Fresh resolution of this exact package set (no lockfile) on current main already produces a single @nestjs/[email protected] — dedup_peer_dependents in the resolver does its job for live resolution.
• The bug surfaces specifically when snapshot_from_lockfile loads a stale lockfile whose five @nestjs/[email protected]_… entries differ only in cycle-unrolling depth. That lockfile-load path constructs ValidSerializedNpmResolutionSnapshot directly from the deserialized data and never runs the resolver's dedup pass, so the spurious variants stick.
• pnpm produces only one entry for the same package set; both the user-visible @nestjs/core and @nestjs/terminus's nested @nestjs/core symlink to that single store entry.

Fix in libs/npm/resolution/snapshot.rs:

• Added SerializedNpmResolutionSnapshot::dedup_equivalent_peer_variants. Groups packages by nv, partitions each group by an effective-dependency signature — dependencies mapped to (name → child nv), plus optional_dependencies, optional_peer_dependencies, and system. Variants with the same signature are mutual supersets in is_superset_node terms, so they're collapsed onto the shortest serialized NpmPackageId and all references (root_packages and per-package dependency ids) are rewritten. Iterates because merging the core variants exposes the pe variants for the next round.
• Called from snapshot_from_lockfile, so stale lockfiles transparently load as the deduplicated graph. No change to live-resolution paths or to the global cache install path.
• "Careful to only dedupe valid sets": variants with genuinely different peer resolutions (e.g. [email protected]_pe@1 vs [email protected]_pe@2) are not merged. Verified by test_dedup_keeps_distinct_peer_resolutions and by the existing peer_deps_with_copied_folders_and_lockfile spec still passing unchanged.
• Two new unit tests in snapshot.rs cover the cycle-unrolling collapse and the legitimate distinct-peer case.
• Manually verified on lucassusanto/nestjs-deno-terminus-issue: only @[email protected] ends up under .deno/, and the NestJS app reaches [NestApplication] Nest application successfully started.

(I considered fixing this purely in resolve_peers_of_node per your preference, but my evidence shows the live resolver already produces a single variant — the leak is entirely through the lockfile-load path that bypasses the resolver. Snapshot-level dedup felt like the least invasive way to fix existing stale lockfiles in addition to whatever the live resolver does. Happy to move the logic if you'd rather have it elsewhere.)

Could we do the fixup on like deno install only? It's not great when people get random lockfile changes on deno run e.g.

@nathanwhit good call — gated. New commit 91df19a:

• Added dedup_lockfile_peer_variants: bool to NpmInstallerFactoryOptions, threaded through NpmResolverManagedSnapshotOption::ResolveFromLockfile { lockfile, dedup_equivalent_peer_variants } and SnapshotFromLockfileParams::dedup_equivalent_peer_variants.
• In cli/factory.rs the flag is set only for add, install (local), cache, ci, remove, and approve-scripts — same set that gets clean_on_install. Everything else (run, serve, test, bench, task, eval, LSP, …) passes false, so deno run against a stale lockfile loads it as-is and won't write back a deduped version.
• The NestJS fix still applies the moment the user runs deno install / deno cache / deno ci — that path rewrites the lockfile cleanly and the installed node_modules ends up with a single physical copy.