[Bug?]: Mono repo and peerDependency : doesn't provide <pkg> , requested by <pkg>

[kopax]

Self-service

• I'd be willing to implement a fix

Describe the bug

When running yarn to install dependency, yarn is emitting a warning that package is not provided, while it is a peerDependency and should be provided also in devDependency.

However, when I provide the peerDependency in devDependency, as I am in a mono repo lerna, it appears that some dependency get installed at the workspace level in another node_modules, which cause typescript compilation error.

Thus, I had to remove them from dependency so they do not get downloaded multiple time

To reproduce

Create a mono repo

error TS2322: Type 'import("/home/dka/workspace/project/packages/utilities/node_modules/ethers/lib.commonjs/providers/network").Network' is not assignable to type 'import("/home/dka/workspace/project/node_modules/ethers/lib.commonjs/providers/network").Network'.

Environment

yarn dlx -q envinfo --preset jest

  System:
    OS: Linux 6.1 Debian GNU/Linux 12 (bookworm) 12 (bookworm)
    CPU: (4) x64 AMD Ryzen 9 7940HS w/ Radeon 780M Graphics
  Binaries:
    Node: 20.10.0 - /tmp/xfs-f4424100/node
    Yarn: 4.3.1 - /tmp/xfs-f4424100/yarn
    npm: 10.5.0 - ~/.nvm/versions/node/v20.10.0/bin/npm

Additional context

No response

[clemyan]

This is one of the fundamental limitations of node_modules resolution -- without using the --preserve-symlinks flag it is impossible to correctly resolve peer dependencies across symlinked dependencies (e.g. workspace)

Say we have this setup:

• workspace-a
  • dev-depends on foo
  • peer-depends on foo
• workspace-b
  • depends on workspace-a
  • depends on foo

If both workspaces' foo dependencies resolve to the same version, then it is deduped to the root node_modules, and all is well.

However, if the two foo dependencies resolve to different versions. Say workspace-a dev-depends on [email protected] but workspace-b depends on [email protected].

The correct behavior in this case is for workspace-a to resolve foo to [email protected] when used as a package (e.g. cd workspace-a && yarn run x) but resolve foo to [email protected] when used as a dependency of workspace-b. However, node_modules resolution can't distinguish the two cases (without --preserve-symlinks), because it only receive the source path (i.e. the path of the requiring module), not the require stack.

Thus workspace-a must either always resolve foo to [email protected] (which breaks the peer-dependency, as you have seen) or always resolve foo to [email protected] (which breaks the dev-dependency). There is no way to satisfy both.

Even removing workspace-a's dev dependency doesn't fully remove the problem. Say we have this:

• workspace-a
  • peer-depends on foo
• workspace-b
  • depends on workspace-a
  • depends on [email protected]
• workspace-c
  • depends on workspace-a
  • depends on [email protected]

We have the same problem of workspace-a must either always resolve foo to [email protected] or [email protected]. You will always have two instances of foo when typechecking either workspace-b or workspace-c.

The only fully correct way to solve this is to run all node processes with --preserve-symlinks (which not all packages are compatible with). Everything else you do will have subtle edge cases which breaks. Alternatively, you can acknowledge it may cause something to break at some point and do whatever works for your case.

[yarnbot]

Hi! 👋

It seems like this issue as been marked as probably resolved, or missing important information blocking its progression. As a result, it'll be closed in a few days unless a maintainer explicitly vouches for it.