[Kumar44developer]

Closes #387.

The problem

In loose mode parseRange filtered out every token that did not match COMPARATORLOOSE and kept whatever was left. So a range containing text that is not range syntax parsed successfully, as something weaker than what was written:

new Range('* (4.1.x  4.1.2)', { loose: true }).format()  // ''        -> matches everything
validRange('* (4.1.x  4.1.2)', { loose: true })          // '*'
new Range('>=1.0.0 (foo)',    { loose: true }).format()  // '>=1.0.0' -> '(foo)' dropped
validRange('* (bogus)',       { loose: true })           // '*'

The first one is the dangerous case. Something written to pin 4.1.2 comes out as *, matching every version. And validRange answering '*' means a caller that validates input before storing it is told the string is fine, then gets a different range than the one it handed in.

(1.2.3) already threw, but only because nothing survived the filter and the empty set was rejected afterwards. A single valid comparator anywhere in the range masked everything else, which is why the behaviour looked arbitrary.

Why the obvious fix is wrong

Rejecting anything unparseable is the first thing to try, and I measured it before writing this: three test files fail, because loose mode relies on that drop for the leftovers of its own normalization. These are all pinned as parsing today:

== 1                    -> >=1.0.0 <2.0.0-0
== 1.0.0 || foo         -> 1.0.0
1.2.3 || 1.2.3= x       -> 1.2.3
1.2.3-dev= 1 || 2.0.0   -> 2.0.0

So the drop is load-bearing and cannot simply go.

The rule this uses instead

A token is dropped exactly as before, unless it carries a character that appears in no comparator and no version — then the range is invalid. A stray == or a bare foo is sloppy range syntax; (foo) is not range syntax at all.

The error is the Invalid SemVer Range the constructor already raises, so no new error type appears in the API. Strict mode is untouched — it already threw Invalid comparator for every one of these.

THROW  "* (4.1.x  4.1.2)"      Invalid SemVer Range: * (4.1.x 4.1.2)
THROW  ">=1.0.0 (foo)"         Invalid SemVer Range: >=1.0.0 (foo)
THROW  ">=1.0.0 [foo]"         Invalid SemVer Range: >=1.0.0 [foo]
THROW  "1.0.0 {x}"             Invalid SemVer Range: 1.0.0 {x}
OK     "== 1"              ->  ">=1.0.0 <2.0.0-0"
OK     "== 1.0.0 || foo"   ->  "1.0.0"
OK     "1.2.3 || 1.2.3= x" ->  "1.2.3"
OK     "1.2.3, <2.0.0"     ->  "<2.0.0"
OK     "v1.2.3"            ->  "1.2.3"
OK     "=1.2.3"            ->  "1.2.3"

One case I found and deliberately did not change

The comma is excluded from that character class on purpose:

validRange('1.2.3, <2.0.0', { loose: true })  // '<2.0.0'

That is the same shape of problem — the 1.2.3 lower bound silently vanishes and the range gets weaker. But it is pinned by an explicit test in test/ranges/valid.js, which tells me it is either intentional or long-grandfathered, and quietly reversing it under a different issue number would be the wrong way to find out. It keeps working, and there is a comment next to the character class saying why. If you want it rejected too I'll do it here or in a follow-up — your call.

Tests

Six rows in the range-parse fixture, which runs every input through all four option combinations, so the parenthesised forms are now asserted invalid in loose and strict alike. Then two focused tests, one either side of the line:

• loose mode does not drop input that is not range syntax — the bracketed forms throw and validRange returns null.
• loose mode still tolerates its own leftovers — == 1, foo, 1.2.3= x, the comma case, v1.2.3, =1.2.3 all still parse. This is the one that would catch a future widening of the check.

The fixture's hardcoded row counts move from 348/335 to 354/341, which is the meta-test in test/classes/range.js noticing the new rows.

Verified with the fix reverted: the new fixture rows and both focused tests fail. With it: npx tap green across all 53 test files, npx eslint . clean.