pnpm@9.0.4 links incorrect peer dependency when multiple versions of the peer dependency exist in a monorepo

[zeusdeux]

Verify latest release

• I verified that the issue exists in the latest pnpm release

pnpm version

v9.0.4

Which area(s) of pnpm are affected? (leave empty if unsure)

Dependencies resolver

Link to the code that reproduces this issue or a replay of the bug

https://github.com/zeusdeux/pnpm9-peer-dep-resolution-bug

Reproduction steps

1. Please clone this repo that reproduces the bug and run pnpm install in the workspace root.
2. Run pnpm why -r rollup. It will report —

    rollup-plugin-visualizer 5.9.2
   └── rollup 4.14.3 peer

3. Run cat packages/package-b/node_modules/rollup-plugin-visualizer/package.json | grep -A3 peerDependencies\". It will report —

    "peerDependencies": {
      "rollup": "2.x || 3.x"
    },

Thus we can see that even though in package-b, rollup-plugin-visualizer has a peerDep on rollup v2 or v3, pnpm links it with rollup v4 which is installed by packages/package-a in the repo.

Describe the Bug

pnpm v9 doesn't seem to respect the peer dependency version as made explicit by some package if there are multiple versions of that peer dependency already in the monorepo.

Expected Behavior

pnpm v9 should use the correct version of the peer dependency as specified by any package.

Which Node.js version are you using?

20.12.2

Which operating systems have you used?

• macOS
• Windows
• Linux

If your OS is a Linux based, which one it is? (Include the version if relevant)

No response

[zkochan]

A peer dependency range is only a suggestion. The most important thing about a peer dependency is that it should be a singleton. If there is a version of the package already installed in the workspace, pnpm will use it instead of installing something new. It is really easy to fix it, just install the version of the peer that you want as a direct dependency.

[zeusdeux]

Thanks for the super quick reply @zkochan!

A peer dependency range is only a suggestion. The most important thing about a peer dependency is that it should be a singleton.

Is this defined anywhere? I don't see any such notes in pnpm docs nor in how npm treats peerDeps — https://docs.npmjs.com/cli/v10/configuring-npm/package-json#peerdependencies

Also, in large monorepos, this is effectively impossible as some teams can choose to stay on certain versions of the dependency while other teams are free to upgrade. The e.g., here we have the build tool rollup wherein some teams depend on and use rollup@5 via 3rd party packages in the monorepo while some use rollup@4. An upgrade by one team should not break another teams code in such a scenario. And this btw works as expected in pnpm@8.

If there is a version of the package already installed in the workspace, pnpm will use it instead of installing something new.

What's weird is that even when pnpm@9 sees both versions of a peerDep, it chooses the latest one and seems to disregard whatever peerDep suggestion was provided by the package. This again worked as expected with pnpm@8.

Given that aligning versions of the peerDep is not currently possible in this large monorepo I speak of, what other alternatives do I have?

[zkochan]

Also, in large monorepos, this is effectively impossible as some teams can choose to stay on certain versions of the dependency while other teams are free to upgrade.

In that scenario you would need to install a different version of the peer dependency as a direct dependency for the subset of projects that use a different version of the peer dependency. Regardless of this issue, you would need to manually set a peer dependency for one of the groups.

[zeusdeux]

In that scenario you would need to install a different version of the peer dependency as a direct dependency for the subset of projects that use a different version of the peer dependency. Regardless of this issue, you would need to manually set a peer dependency for one of the groups.

Thank you for the workaround @zkochan!
Any reason why this works as expected in v8 and not in v9 btw?