[email protected] links incorrect peer dependency when multiple versions of the peer dependency exist in a monorepo about pnpm HOT 4 OPEN

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.

from pnpm.

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?

from pnpm.

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.

from pnpm.

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?

from pnpm.