pnpm dedupe --check --only <packages>

Contribution

• I'd be willing to implement this feature (contributing guide)

Describe the user story

Problem

In a monorepo with a shared dependency catalog, we want to enforce that certain critical packages (e.g. react, zod, @scaleway/sdk-client, @ultraviolet/ui) never have more than one version installed across the workspace. This matters because: Multiple versions of UI libraries cause duplicate React contexts, style injections, and bundle bloat Multiple versions of SDK clients create type mismatches across packages Catalog-based monorepos (catalogMode: manual) intend to pin one version, but transitive deps can still pull in extras Currently there’s no single pnpm command to check this. The closest options: pnpm dedupe --check checks all packages — can’t scope it to a subset we care about pnpm why -r prints Found N versions but has no exit code signal and isn’t scriptable for CI pnpm list --json -r requires parsing the full dependency tree

Describe the solution you'd like

Proposed solution

Extend pnpm dedupe --check with an --only (or --packages) flag that scopes the check to a specific list of package names: pnpm dedupe --check --only react,react-dom,zod,@scaleway/sdk-client Behavior: Only checks the listed packages for duplicate versions Exits with code 1 if any listed package has more than one version in the lockfile Exits 0 if all listed packages have exactly one version Output shows which packages have duplicates and their versions (like pnpm why already does)

Describe the drawbacks of your solution

False sense of security. A green check means “no duplicates in the listed packages,” not “no duplicates anywhere.” Users may treat it as a blanket guarantee and miss duplicates in unlisted deps. Manual list maintenance. The --only list must be hand-maintained. New critical deps added later won’t be covered unless someone remembers to update the list — the exact failure mode the check is meant to prevent. Can’t distinguish wanted vs unwanted duplicates. During a major-version migration (e.g., React 18 → 19, or zod 3 → 4), you legitimately want two major versions coexisting for a transition period. A blanket “fail if >1 version” can’t express “v4 and v5 OK, v4.0.1 and v4.0.2 not OK.” Peer-context variations. pnpm tracks the same version resolved under different peer constraints (we saw peer#1410 (2 variations)). A naive version count may flag these as duplicates when they’re the same version — the check needs to count distinct versions, not instances. Overloads dedupe semantics. pnpm dedupe is about semver-range reconciliation. --check for version uniformity is a different concept (enforcement, not resolution). Coupling them in one command muddies the API — does --only react mean “only dedupe react” or “only check react”? The mutating and --check forms would need to agree, which is fragile. Duplicated catalog role. For catalog-based monorepos, the catalog is the source of truth for intended versions. A lockfile-level check duplicates that and can drift. The more correct enforcement is at install time: “warn if a non-catalog version of a catalog package is resolved” — which pnpm could do natively without a new flag. Pushes judgment to the maintainer. Scoping to a list means someone must decide which packages are “safe to have duplicates” (most transitive deps) vs “must be unique” (React, zod, UI libs). That’s domain knowledge the tool can’t infer — so the check is only as good as the list.

Describe alternatives you've considered

A separate pnpm check-duplicates <pkg...> command, but that duplicates logic already in pnpm dedupe / pnpm why. Scoping the existing --check is a smaller surface area.