[BUG] Installing peer dependency pre-releases seem not possible

[medikoo]

Is there an existing issue for this?

• I have searched the existing issues

This issue exists in the latest npm version

• I am using the latest npm

Current Behavior

We have a pre-release of Serverless Framework, installable via serverless@pre-3.

We'd love the users to test it, but in many cases, plugins have serverless configured as peer dependency, and then users when installing the plugin see the error as:

Expected Behavior

Best would be if npm ignores installed pre-preleases and in such cases does not attempt to install "correct" version of peer dependency (just listing warning would be ok)

Steps To Reproduce

In an empty folder run the following commands:

npm install serverless@pre-3
npm install serverless-offline

Environment

• npm: 8.1.4
• Node: v16.13.0
• OS: macOs 11.6

[ljharb]

Prereleases aren't included in >=, and the peer requirement also excludes v3 or higher anyways.

What this means is, users can't test a v3 prerelease, unless the peer range is updated to allow for it, because it's explicitly marked as incompatible. It would likely cause far more problems than it solves to allow for this case.

Another alternative is the user using "overrides", to override v2 and replace it with the v3 prerelease.

[nlf]

the problem is that pre-3 doesn't match the required peer dependency range, what you could do though is use overrides:

{
  "dependencies": {
    "serverless": "pre-3",
    "serverless-offline": "^8.8.0"
  },
  "overrides": {
    "serverless": "$serverless"
  },
}

here i'm using a reference to the direct dependency to inform npm of what version to override everything with. with these changes i'm able to get both packages installed and working just fine. feel free to reopen if you continue to have problems!

[medikoo]

the problem is that pre-3 doesn't match the required peer dependency range, what you could do though is use overrides:

@nlf that won't be natural and it also greatly complicates install instructions for users (we need to ask them to not only run npm install but also manipulate package.json which feels not right)

In such case I believe most UX-friendly behavior is to assume mapping is correct but list a warning that no mapping is attempted. Especially that pre-releases do not reflect static ranges (where the given version will always match the given range) - there's never a guarantee that installed peer release conforms to given pre-release tag.

[ljharb]

Prereleases aren't supposed to be UX-friendly - if it's ready for users to test, why isn't it a full v3?

[medikoo]

Prereleases aren't supposed to be UX-friendly - if it's ready for users to test, why isn't it a full v3?

@ljharb in software engineering (especially when deal with more complex multi-functional software) we use different release cycles (it's not only stable channel that's released for public).

Check: https://en.wikipedia.org/wiki/Software_release_life_cycle (in our case pre-relese corresponds to Beta or Release candidates)

[ljharb]

I'm aware of that, but that's not something that semver or the npm ecosystem are commonly used for nor are well-designed for.

[k2snowman69]

I know this is a bit old but I just ran into this exact issue and maybe I can give our example as to why this is a barrier to get to a "full v3".

Our system has a few checks before we release a production package (as everyone should) and part of these checks is E2E testing on a selection of high risk repos. Our process is we release a beta package, then some automated systems will pick up that a new beta package upon released, create PRs, and start a CI pipeline for each of the spot check repos which ideally would have an internal deployed server so if someone wanted to manually test they could. We want these branches to be as minimally different from our mainline branch so they are running npm ci just like our mainline branch does. Once all these E2E checks are complete, verified, deployed on internal test sites, verified by QA (possibly including manual testing), it's only then we release a "full package". Once a full package is released, it's consumed by all repos within our company, not just those selected for spot-check.

However because of this preproduction exclusion, we aren't able to deploy our E2E spot-check repos to pre-prod environments. Hilariously, this preproduction exclusion is actually what's preventing us from doing our due diligence in testing so we feel comfortable releasing a production package.

In my case it's a chicken and egg problem. For now we've resorted to running npm ci --force which it's bad for all the reasons you added npm ci however we have no other options.

Hopefully this might shed some light on a situation where consuming a preproduction package in a preproduction environment would still need npm ci to succeed.

If I don't hear a response I'll assume it's due to this ticket being closed and I'll create a new ticket for discussion.