Why does `>1.2` throw as an invalid comparator?

[jsumners]

node-semver/test/fixtures/range-exclude.js

Line 68 in d17aebf

['>1.2', '1.2.8'],

I am trying to understand why npx -r '>1.2' 1.2.8 results in 1.2.8 not satisfying the range. I think >1.2 should expand to >1.2.0 <1.3.0 which would mean 1.2.8 satisfies. But stepping through the tool, I see it hits this path:

node-semver/classes/comparator.js

Lines 37 to 42 in d17aebf

	const r = this.options.loose ? re[t.COMPARATORLOOSE] : re[t.COMPARATOR]
	const m = comp.match(r)
	if (!m) {
	throw new TypeError(`Invalid comparator: ${comp}`)
	}

The result being m === null and the TypeError is thrown.

[ljharb]

>1.2 does not expand to >1.2.0, it equates to >= 1.3. In other words, > 1.2 means that no 1.2.x version can satisfy it.

[jsumners]

I see. Thank you.

[jsumners]

Sorry, I'm reopening this. I think this line is confirming your answer @ljharb:

node-semver/README.md

Lines 164 to 166 in d17aebf

	or `1.1.0`. The comparator `>1` is equivalent to `>=2.0.0` and
	would match the versions `2.0.0` and `3.1.0`, but not the versions
	`1.0.1` or `1.1.0`.

But further down we have:

node-semver/README.md

Lines 316 to 321 in d17aebf

	A partial version range is treated as an X-Range, so the special
	character is in fact optional.
	* `""` (empty string) := `*` := `>=0.0.0`
	* `1` := `1.x.x` := `>=1.0.0 <2.0.0-0`
	* `1.2` := `1.2.x` := `>=1.2.0 <1.3.0-0`

This seems to be a conflict to me.

[wraithgar]

1.2 is not the same as >1.2

[jsumners]

1.2 is a component of >1.2. The version string should still expand the same.

[ljharb]

1.2 does not expand to 1.2.0. It expands to 1.2.x, and >1.2.x indeed excludes any 1.2.

[jsumners]

It expands to 1.2.x

Which expands to 1.2.0. Thus, >1.2 should expand to >1.2.0, right?

[ljharb]

No, it does not expand to 1.2.0. It can't expand without a concrete list of existing versions, and it will always match the latest 1.2, not the .0

[jsumners]

I'm just not seeing the rule you're basing that on. If the readme isn't the source of truth for the expansion rules, please point me to the right document.

[ljharb]

It’s not documented that i can see, but it’s common sense - would “1.2” be satisfied by 1.2.99? Obviously yes, because it’s a range, not a short way to express one version.

[jsumners]

Sorry, you've just confused me even more. I originally asserted that 1.2.8 should satisfy >1.2. Your response was that it shouldn't. Now you're suggesting it should.

[ljharb]

1.2.8 certainly satisfies 1.2. It certainly does not satisfy >1.2 (which is the same as >= 1.3).

[aMarCruz]

This discussion will continue for years until there's an npm specification :)

@jsumners ,
As you, I'm surprised me because I thought semver.coerce() was being applied before the comparison.
Then I reasoned that it was checking for inclusion in a set, so the logical thing to do was to convert '1.2' to '1.2.x' and not coerce to '1.2.0' (the same for 1 to 1.x.x).
After that, the results in this list made perfect sense to me...

semver.satisfies('1.2.0', '1')        // true -- '1' is converted to '1.x.x'
semver.satisfies('1.2.0', '1.2')      // true -- '1.2' to '1.2.x' an so on
semver.satisfies('1.2.0', '1.2.0')    // true
semver.satisfies('1.2.0', '=1.2')     // true -- The '=' makes no difference
semver.satisfies('1.2.0', '=1.2.0')   // true
semver.satisfies('1.2.0', '~1.2')     // true -- '~#.#' is equal to '#.#.x'
semver.satisfies('1.2.0', '~1.2.0')   // true
semver.satisfies('1.2.0', '<1.2')     // false
semver.satisfies('1.2.0', '<1.2.0')   // false
semver.satisfies('1.2.0', '<=1.2')    // true
semver.satisfies('1.2.0', '<=1.2.0')  // true
semver.satisfies('1.2.0', '>1.2')     // false
semver.satisfies('1.2.0', '>1.2.0')   // false
semver.satisfies('1.2.0', '>=1.2')    // true
semver.satisfies('1.2.0', '>=1.2.0')  // true
semver.satisfies('1.2.0', '^1.2')     // true
semver.satisfies('1.2.0', '^1.2.0')   // true -- '^#.#' is equal to '#.x.x'

...as this...

semver.satisfies('1.2.8', '1')        // true
semver.satisfies('1.2.8', '1.2')      // true
semver.satisfies('1.2.8', '1.2.0')    // false
semver.satisfies('1.2.8', '=1.2')     // true
semver.satisfies('1.2.8', '=1.2.0')   // false
semver.satisfies('1.2.8', '~1.2')     // true
semver.satisfies('1.2.8', '~1.2.0')   // true
semver.satisfies('1.2.8', '<1.2')     // false
semver.satisfies('1.2.8', '<1.2.0')   // false
semver.satisfies('1.2.8', '<=1.2')    // true
semver.satisfies('1.2.8', '<=1.2.0')  // false
semver.satisfies('1.2.8', '>1.2')     // false
semver.satisfies('1.2.8', '>1.2.0')   // true
semver.satisfies('1.2.8', '>=1.2')    // true
semver.satisfies('1.2.8', '>=1.2.0')  // true
semver.satisfies('1.2.8', '^1.2')     // true
semver.satisfies('1.2.8', '^1.2.0')   // true

satisfies does not work as other semver methods ...gt, lt, etc.
The conclusión is to use the full semver (n.n.n) if you're unsure.

This is the gist with the source