Skip to content

[BUG] npm install fails when installing with prereleases of peerDependencies #2087

Closed

Description

@alasdairhurst

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 "A@1.5.0". 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 A@1.5.1-0 or future versions (that are 100% compatible) such as A@1.9.4-5, 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 A@1.5.1-0 alongside module B
  6. See an ERESOLVE error "unable to resolve dependency tree" "Could not resolve dependency peer "A@^1.5.0" from "B@1.0.0"
  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

Activity

  1. added
    Bugthing that needs fixing
    Needs Triageneeds review for next steps
    Release 7.xwork is associated with a specific npm 7 release
    on Oct 30, 2020
  2. alasdairhurst commented on Oct 30, 2020

    @alasdairhurst
    Author

    Looks like I may have been wrong here...
    a peer of "^1.5.0-0" seems to include all future prereleases before 6.0.0

  3. alasdairhurst commented on May 11, 2021

    @alasdairhurst
    Author

    I was wrong. a peer of "^1.5.0-0" doesn't include all future prereleases

    1.5.0-0 won't match 1.6.0-0

    This is a bit of an issue now i since NPM installs peer dependencies by default.

  4. darcyclarke commented on May 14, 2021

    @darcyclarke
    Contributor

    @alasdairhurst Thanks for filing this! Since this is working as intended, can you please open an RFC issue with some details on how you could/would like to see this changed?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Release 7.xwork is associated with a specific npm 7 release

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions