[Bug?]: Yarn 4's strict dependency resolution prevents local package linking when peer dependencies differ

[polus-arcticus]

Self-service

• I'd be willing to implement a fix

Describe the bug

Title: Yarn 4's strict dependency resolution prevents local package linking when peer dependencies differ

Description

When attempting to link a local package using either yarn link, the portal: protocol, or relative linking, Yarn 4 enforces strict peer dependency resolution that prevents linking when the linked package has different versions of shared dependencies. However, the same package works perfectly fine when installed directly from npm, suggesting this is a linking-specific issue rather than a fundamental dependency conflict.

Steps to Reproduce

3. Yarn 4 will fail with an error about conflicting dependencies:

   Cannot link package-b into package-a dependency viem@npm:2.20.1 conflicts with parent dependency viem@npm:1.18.4
   

4. However, installing the same package from npm works without issues:

   {
     "dependencies": {
       "package-b": "^1.4.0"  // Works fine when installed from npm
     }
   }

Expected Behavior

The packages should link successfully, allowing for local development and testing, even with different versions of shared dependencies. The linked package should maintain its own dependency tree, just as it does when installed from npm.

Actual Behavior

Yarn 4 prevents the linking operation entirely, citing dependency conflicts, regardless of the linking method used. This is inconsistent with the behavior when installing the same package from npm, which works without issues.

Environment

• Yarn version: 4.1.0
• Node version: 18+
• Operating system: Linux

Related Issues

• This behavior seems to be a regression from Yarn 3, which allowed more flexible linking
• Similar issues have been reported with workspace dependencies

To reproduce

1. Have two packages:

   • Package A (consumer) with dependency viem@^1.18.4
   • Package B (to be linked) with dependency viem@^2.20.1

2. Try to link Package B into Package A using any of these methods:

   # Method 1: Using yarn link
   cd package-b
   yarn link
   cd ../package-a
   yarn link package-b

   or

   // Method 2: Using portal protocol in package.json
   {
     "dependencies": {
       "package-b": "portal:../package-b"
     }
   }

   or

   // Method 3: Using relative path in package.json
   {
     "dependencies": {
       "package-b": "file:../package-b"
     }
   }

Environment

- Yarn version: 4.1.0
- Node version: 18+
- Operating system: Linux

Additional context

Additional Context

• This behavior makes local development more difficult, especially when working with packages that have different version requirements
• The current workarounds (using --private or --ignore-engines flags) don't work
• This is particularly problematic in monorepos or when developing packages that need to be tested with different dependency versions
• All three common methods of local package linking (yarn link, portal protocol, and relative paths) are affected by this issue
• The fact that the same package works when installed from npm but fails when linked locally suggests this is a linking-specific issue rather than a fundamental dependency conflict