Npm Including all range of pre-release when defining peer-dependency

Question

I am maintaining an NPM package (lets say it as package-A) that relies on an another NPM package(package-B) to function. Therefore, I am in need to add that package as peer-dependency into the package.json, so that npm and the user can be sure that everything is correct.

The problem is, package-B use pre-release versioning. I am well aware that it uses semver wrong, but I am not able to change the company policy, yet. Meanwhile enforcing to use proper versioning will happen. The semantic is like this:

• 1.0.1-alpha.X -> Unstable releases for testing and bleeding edge content
• 1.0.1-beta.X -> For every seemingly stable version (like rc)
• 1.0.2 -> When the package is production ready.

So basically, the patch version increases when there is another production release.

Case: Because of the versioning, I need to include every package except major one to match as peer dependency, together with pre-releases.

The need is basically ^1.0.0 with everything including pre-releases that happens to have 1 as major as peer dependency

• ^1.0.0 -> Does not include pre-releases
• ^1.0.0 || >=1.0.0-beta.X -> Does not include e.g. 1.0.1-beta.1
• * -> Does not include pre-releases
• ^1.0.0 || >=1.X.X-beta.X -> Does not work.

On semver, there is a parameter called --include-prerelease which I think does what I need, specific to semver commands obviously.

react package on NPM has similar versioning system with proper usage of pre-release. E.g. it has 16.0.0, 16.0.0-alpha.1 and 16.6.0-alpha.0. I basically need to include all this on a single range.

Disclaimer: Minor version is changed when there is a breaking change going on. Yet again, I am well aware that this versioning is not up to semver regulations and advising it unfortunately will not solve the problem at hand.

Filiform

> the patch version increases when there is another production release. the "pre-release" word and the semver 2.0 docs (items 9 to 11), as well as this big package's releases, all lead me to believe the order of released versions should be 1.0.1-alpha.X -> 1.0.1-beta.X -> 1.0.1, because it would mean that the alpha and beta are candidates for the 1.0.1 version – Pueblo

Answer 1

https://classic.yarnpkg.com/en/docs/dependency-versions#toc-pre-release-tags

If a comparator includes a version with a pre-release tag it will only match against versions that have the same major.minor.patch version.

You can only include pre-releases of specific versions.

>=1.0.0-beta includes 1.0.0-beta.X, but not 1.0.1-beta.X

You can play around with the semver pre-release ranges on https://semver.npmjs.com/ Lookup the package @artsy/reaction they have bunch of pre-releases

Effluvium

Thanks, I can safely assume that it isn't possible to accomplish this feat. That's a bummer. – Filiform

You'd have to specify every version. It can be done like ^1.0.0-beta || ^1.0.1-beta etc. It's possible, but not practical. – Insipid

Answer 2

I don't know if this applicable to this use case, but in situations where I wanted a peer dependency to accept any prerelease, I've done something like:

"peerDependency": {
  "depName": "^1.0.0-0"
}

I'm not sure of the exact term for the trailing -0 of the semver, but I've considered it a wildcard, of sorts.

---

EDIT: To provide some more context. My experience is limited to doing this with NPM, but I would hope how various package managers handle semantic versioning would be the same. In the case of npm, it uses the semver module for evaluating semantic versions. Here's an rough example of how I think npm evaluates prerelease versions.

import semver from 'semver';

const accepted = '^1.0.0-0';
const prereleases = [
  '1.0.1-alpha.0',
  '1.0.6-beta.0',
  '1.0.6-next.0',
  '1.3.0-0.64-34-aerf3asdf33'
];

for(const prerelease of prereleases) {
  const satisified = semver.satisfies(prerelease, accepted, { includePrerelease: true });
  console.log('satisified', prerelease, satisified);
}

Settles

Hmm so does it accept all there is for prerelease tags? I will try this and if it works, I'd like to update all the packages with this ruleset. – Filiform

I believe it does. I've only dealt with this in the context of NPM, but in that case, it uses the semver module to determine if a version matches the provided semantic versioning. I'll update my answer with a code snippet to show how you can test against that module. – Settles

THanks again for your feedback. I was going to test this but for some reason, it accepts both prereleased versions and normal versions even thou I only include normal versions, therefore I couldn't reproduce the problem. I will try again later when I have to fiddle with the packages next. – Filiform