Peer Dependency Hoisting Across Yarn Workspaces: Unresolved Behavior

Goal

Determine how Yarn resolves peer dependencies when multiple workspaces share a common peer, and whether hoisting or nohoist directives affect runtime resolution.

Constraints & Uncertainty

In Yarn 2+ (Berry) the Plug'n'Play mechanism eliminates node_modules, yet workspace-level hoisting still occurs according to the highest compatible version. The "nohoist" pattern applies to package names, not paths, and may or may not prevent a peer dependency from being hoisted. Additionally, Yarn’s "packageExtensions" can declare missing peers for third‑party packages, but it is unclear how this interacts with workspace hoisting rules.

Specific Questions

• When a workspace declares a peer dependency that is also a direct dependency of another workspace, does Yarn hoist the peer to the root or keep it isolated?
• Does the "nohoist" configuration block hoisting of peer dependencies, or is it ignored for peers?
• How does Yarn’s PnP resolution map represent peer dependencies that are not hoisted, and can this lead to phantom runtime errors?