Fix ^ and ~ range matches on x.y patterns

[crisptrutski]

😨

[guybedford]

👍

[lookfirst]

@guybedford Why are you allowing non-legal semver ranges? The PATCH version is a required field in semver.

http://semver.org/

"2. A normal version number MUST take the form X.Y.Z where X, Y, and Z are non-negative integers, and MUST NOT contain leading zeroes. X is the major version, Y is the minor version, and Z is the patch version. Each element MUST increase numerically. For instance: 1.9.0 -> 1.10.0 -> 1.11.0."

[lookfirst]

~0 is not a legal semver

[crisptrutski]

Hey @lookfirst

You seem to be confusing versions and constraints.

While http://semver.org defines the spec for versions and the relative order of versions, it says absolutely nothing about a syntax for constraints.

This is a long reply to give you some background and explain the reasoning, but the TLDR is that these expressions can be used today with jspm and npm, but before this PR they would behave inconsistently. You can try all of these test cases at http://semver.npmjs.com/.

---

Essentially every package managers has invented their own grammar and syntax, and the only thing you can generalize is that they have >, >=, < and <= and intersection. For example npm's ^1.x would be ~>1.0 to RubyGems (and a "semver range" and "pessimistic constraint" in respectively specs). No equivalent for npm's ~ prefix exists, but it can be expressed via intersection.

Not only is there no single standard for ranges, the specs themselves have been moving targets. Looking at npm, the meaning of <= 3.x and ^x.y have changed in the last year based on feedback from the community. For a long time ~ was the recommended prefix, but some time later ^ was introduced and rapidly adopted.

Lastly package managers need to support non-semver versions, because not all old projects switch (or users need to use old versions), people make mistakes, and others maintainers dislike semver. At the very least exact matches must be supported for non semver versions, but some package managers support ranges on these non semver values also.

This sounds very glum, but npm has blazed the trail for JS, not only establishing the conventions for other tools to share, it has the possibly the most massive grammar around.. multiple wildcards, partial versions, multiple range shorthands, disjunction, etc. For another massive grammar you could compare jsemver, which formalized it (although actually that spec is out of date, it's added new prefixes).

Coming back to your examples, ~0 is most certainly a legal expression.

If you wanted to split hairs then ^1 is not in their spec, and it would need to be ^1.x - but the implementation accepts and treats both strings identically.

Why does jspm explicitly support ^1 instead of specifying ^1.x instead? Because jspm does not support wildcards directly. In fact, most of the node-semver range spec is not supported - because they're mostly considered anti-patterns in a package.json (and therefore to jspm install also)

Perhaps jspm's chosen subset is too limited, to turn your complaint around completely. It's certainly simpler to extend it conservatively.

[lookfirst]

@crisptrutski

While http://semver.org defines the spec for versions and the relative order of versions, it says absolutely nothing about a syntax for constraints.

Thanks for the super long response, but that sentence above solidified it all for me. =) I wasn't thinking of it like that, so massive kudos for explaining it all. I definitely learned something today, which I really appreciate!

[crisptrutski]

No problem - was useful for me too (only read up on this to answer your challenge) 😉

[jameswyse]

Great explanation, I'd been confused about that myself. Thanks @crisptrutski :)