ERESOLVE in force mode

[isaacs]

This shouldn't happen.

{
  "devDependencies": {
    "webpack-dev-server": "^3.11.0",
    "@pmmmwh/react-refresh-webpack-plugin": "^0.4.3"
  }
}

npm/cli#2123

[billyjanitsch]

One note: the package.json you have there actually demonstrates two distinct things.

In theory, npm should be able to install a valid tree here. Namely, webpack@4 is compatible with all of the peer requirements, including transitive ones. (Sure enough, if you add "webpack": "^4.0.0" to the package.json, the install completes without error.) This seems like a potentially-unrelated bug in npm's ability to search for valid resolutions of peer constraints?

But there's also the case where there isn't a valid resolution, such as:

{
  "devDependencies": {
    "webpack-dev-server": "^3.11.0",
    "webpack": "^5.0.0"
  }
}

This is the case that I intended to point out in npm/cli#2123.

Both cases demonstrate the issue with --force, but I just wanted to make sure that this doesn't get conflated with the fact that there actually happens to be a valid resolution for your package.json.

[isaacs]

Thanks! Yes, both should work with --force, and the first should resolve without needing it.

[isaacs]

Ah, so this is interesting. Two factors at play here.

First of all, webpack 5 peer-depends on terser-webpack-plugin@^5.0.3 which peer depends on webpack@^5.1.0. So, when we attempt to check if we can replace webpack@5.4.0 with webpack@4.44.2, we check to see if webpack@4.44.2 would satisfy all the deps on webpack@5.4.0, and find terser-webpack-plugin there depending on it. This of course should be a non-issue, because terser-webpack-plugin would be gone if we replaced webpack 5.4.0 with 4.44.2.

That would normally be fine, especially in --force mode, at least for the first place we try to put it, because that would typically be the peerSetSource (ie, the thing that depends on the thing that is bringing in all these peer deps). Essentially, we always prioritize having a peer set nested under its source dependent, because that is literally the only place it can go, so anything deduped up to that level gets booted and re-parented deeper in the tree.

However, in this case, the peerSetSource also itself has a peer dep on webpack, so we start the search further up the tree (since a peer cannot be nested under its peer dependent.)

Because of this extra second hiccup, we don't go into the more aggressive overriding code path (since we assume we don't have to, since we're just looking for an optimization anyway).

A solution here may be to give the first place we look the special treatment, if we have skipped past the peerSetSource.

Investigating.

[billyjanitsch]

First of all, webpack 5 peer-depends on terser-webpack-plugin@^5.0.3

Minor correction: webpack@5 directly- (not peer-) depends on terser-webpack-plugin@^5.0.3.

[isaacs]

Ah, ok. Well, same effect :) There's a thing that's holding webpack@5 in place, but we shouldn't care.

Got a fix for it by gathering the dep set when we check for replaceability, but now getting some extraneous metadeps left behind. Should have a fix ready for Friday's npm release, most likely.