Current Behavior:

As a developer of module "A", i want to use prerelease versions for development. Module "A" has a variety of plugins. let's call one of them "B".

Module "B" uses a certain feature only introduced in "[email protected]". It makes sense to use peerDependencies for this.
Inside "B"'s package.json we have this:

"peerDependecies": {
  "A": "^1.5.0"
} 

This makes it clear that "A" should be installed alongside "B" and that it should work with at least 1.5.0, and any future minor and patch versions but not any future major version (potentially a separate issue)

Unfortunately, semver doesn't include prereleases in it's calculation.

That means that when i release [email protected] or future versions (that are 100% compatible) such as [email protected], these will not match the peer dependency requirement.

Now, this was previously just an issue with semver (sort of) that resulted in warnings in npm when you tested with these prerelease modules and plugins. With npm@7 this now results in big fat error on install forcing you to either use --force or --legacy-peer-deps.

I was a little worried about this behavior when i heard of the change in npm@7 since the other option was that the latest matching peerDependency would be installed, leaving two different versions of "A" in node_modules which could potentially have been a disaster depending on how the plugins were used by A.

This seems like it's possibly a requirement for semver to support ranges which include prereleases, because now all you can do is say something like >=1.5.0-0 which will only ever match 1.5.0 preleases and not future prereleases (unless i'm missing a syntax) Either way, all developers who are publishing modules which have a plugin framework would have to make use of the new semver syntax for including prereleases, or face issues.

I'm a little surprised something like this wasn't pointed out already, so i've a feeling i'm missing an important feature or discussion.

Expected Behavior:

The expected behavior is to install a module B (which has a peer dependency A) alongside any prereleases of A spanning multiple versions which match the range provided in module B, without an errors, warnings, or multiple versions of A being installed.

As mentioned above, i understand it's related to semver constraints so technically working as expected. The problem is that it now causes huge issues for these types of modules and wasn't a problem previously. I expect to still be able to use peerDependencies, and the peer is not optional.

Steps To Reproduce:

1. Create module A version 1.0.0 and pack it up
2. Create module A version 1.5.1-0 and pack it up
3. Create module A version 1.9.4-5 and pack it up
4. Create a module B (version doesn't matter, let's say 1.0.0) with a peer dependency of A at least 1.5.0 (^1.5.0)
5. Create a third module and install module [email protected] alongside module B
6. See an ERESOLVE error "unable to resolve dependency tree" "Could not resolve dependency peer "A@^1.5.0" from "[email protected]"
7. Change module A to 1.9.4-5 and install
8. See the same error as 6.
9. Change module a to 1.0.0
10. See the same error as 6 (this time it's expected)

Environment:

• OS: MacOS Catalina
• Node: 15.0.1
• npm: 7.0.3