An aliased package causes an unsolvable peer dependency warning

[octogonz]

pnpm version: 6.29.1

Code to reproduce the issue:

1. Create a package.json file:

{
  "name": "repro1",
  "version": "1.0.0",
  "dependencies": {
    "webpack5": "npm:webpack@~5.68.0"
  }
}

2. Run pnpm install

Expected behavior:

It should install without errors. (Because if we did "webpack": "~5.68.0" instead, it would install without errors.)

Actual behavior:

 WARN  Issues with peer dependencies found
.
└─┬ webpack
  └─┬ terser-webpack-plugin
    └── ✕ missing peer webpack@^5.1.0
Peer dependencies that should be installed:
  webpack@^5.1.0

The problem is that terser-webpack-plugin has a peer dependency on webpack which is normally satisfied by webpack. But webpack has been renamed to webpack5, so PNPM's validation considers the dependency to be unsatisfied.

More details

In our case, the reason for aliasing the package is that we're developing a plugin that targets both Webpack 4 and Webpack 5:

{
  "name": "repro2",
  "version": "1.0.0",
  "peerDependencies": {
    "@types/webpack": "^4.39.8",
    "webpack": "^5.35.1"
  },
  "peerDependenciesMeta": {
    "@types/webpack": {
      "optional": true
    },
    "webpack": {
      "optional": true
    }
  },
  "devDependencies": {
    "@types/webpack": "4.41.24",
    "webpack5": "npm:webpack@~5.68.0",
    . . .
  }
}

Questions:

1. With PNPM's installation strategy, is it even possible to create symlinks that would enable terser-webpack-plugin's peer to be satisfied by the webpack5 alias? I'm not sure whether this is solvable. (?)
2. If it's not solvable, maybe PNPM's validation should ignore this edge case?

Additional information:

• node -v prints: 14.17.0
• Windows, macOS, or Linux?: Windows

[zkochan]

If this works with Yarn and/or npm (when --legacy-peers are used), then it we should make it work with pnpm as well.

[RexSkz]

I think this issue may become more necessary with the complexity of frontend projects grows.

If a project becomes too large and we want to upgrade a dependency (maybe a component library) by page, it's necessary to have different versions of one package, such as:

# old version
pnpm i my-library@1
# old version, which has a peer dependency my-library
pnpm i my-hoc-library@1

# new version
pnpm i my-library-next@npm:my-library@2
pnpm i my-hoc-library-next@npm:my-hoc-library@2

In PNPM, it will print these errors, even if my-hoc-library@2 has a peer dependency my-library@2:

.
└─┬ my-hoc-library 2.0.0
  └── ✕ unmet peer my-library@2.0.0: found 1.0.0

And PNPM also generates the wrong content in .pnpm - a package my-library@4 in my-hoc-library@5.

A temporary way to fix

Currently I can fix my project by manually editing pnpm-lock.yaml and executing pnpm i:

  packages:
    /my-hoc-library/2.0.0-xxxxxx:
      dependencies:
-       my-library: 1.0.0
+       my-library: /my-library/2.0.0-xxxxxx

But this can be hard if the dependency graph is complex. 😢

[RexSkz]

PR #6220 should resolve this issue.

In PNPM 7.29.3:

After the PR:

This should be considered a breaking change because it changes the way PNPM resolves peer dependencies and generate the node_modules.