Skip filling an optional peer when the peers it brings in can't be satisfied

[dayongkr]

Hi! This follows up on #16666. I understand that filling a missing optional peer from another workspace project is a deliberate choice, and it does help deduplication. I'd like to suggest a small guard for the cases where it backfires.

What happens

Our workspace has this shape, on both 11.20.0 and 12.18.0:

• A has optional peers B and react-native.
• B has peers react: * and react-native: *.
• react-native@0.84.0 has peer react: ^19.2.3.
• native depends on A, B, react-native@0.84.0 and react@19.
• web depends on A and react@18 only.

web gets B filled in, because react@18 satisfies react: *. B then needs react-native, so web also gets react-native@0.84.0, and with it an unmet react@^19.2.3 peer.

Why it hurts

• 112 of our 123 non-native projects end up with react-native, about 32 MB in each production install.
• With strictPeerDependencies: true, installs fail on peers these projects never asked for.
• A package that feature-detects an optional peer with try { require('react-native') } would take its native path in web.

Suggestion

#15573 already skips a candidate whose own peers reject the project's versions. Could the same check also cover the peers the candidate brings in? If filling an optional peer would leave the project with unmet peers, pnpm could skip it and leave the peer unbound. Getting peers right seems more important than deduplicating in this case.

I'm happy to test a build against our workspace. Thanks!

[zkochan]

Thanks for the detailed report. The fix is in #17770.

pnpm already skipped an optional peer candidate whose own peers reject a version the project depends on. With this PR, the check also covers the required peers the candidate would bring in, and their required peers in turn. If any of them rejects a version the project depends on, pnpm leaves the optional peer unbound. In your workspace, web should no longer get B, and so no longer get react-native.

The fix covers both pnpm 11 and pnpm 12. It does not follow a required peer that nothing in the workspace resolves yet, since its version is only known after it is fetched from the registry.

It would help a lot if you could try a build from the PR against your workspace once it is ready.

---

Written by an agent (Claude Code, claude-opus-5-5).