Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[pull] master from npm:master #9

Open
wants to merge 19 commits into
base: master
Choose a base branch
from
Open

[pull] master from npm:master #9

wants to merge 19 commits into from

Conversation

pull[bot]
Copy link

@pull pull bot commented Jul 9, 2020

See Commits and Changes for more details.


Created by pull[bot]. Want to support this open source service? Please star it : )

raphaelzulliger and others added 8 commits April 14, 2020 09:35
In semver v4, the ranges were simplified in 2331a9e "to remove -0
everywhere". This had the unintended side effect of including the
endpoint version's prerelease versions in the resulting range, as
lt('1.0.0-0', '1.0.0') === true.

Tests are updated, adding -0 to the maximal endpoints. One test is moved
from range-include to range-exclude, comparing 2.0.0-rc1 against ^1.0.0

Fixes #223
Fixes #254

EDIT(isaacs): Updated to resolve conflicts on master branch.

PR-URL: #320
Credit: @eemeli
Close: #320
Reviewed-by: @isaacs
This one didn't cause any bugs, but it's more for consistency and
future-proofing.

When a range like '<=1' is translated to 'anything less than 2.0.0', it
should be expressed as '<2.0.0-0' to prevent prerelease 2.0.0 versions
as well.

It didn't cause any problems with intersection or range satisfying
because it would only treat 2.0.0-pre as satisfying <2.0.0 when
includePrerelease was set, and if includePrerelease was set, then it
would add the -0 to the less-than comparator.

Nevertheless, all other areas where we use a <X.Y.0 range, we add the -0
prerelease in order to force the boundary of the set to exclude
prereleases on that version, which is good defense in depth to prevent
other errors with intersection and subsets seen previously.
There are a few cases that lead to Range's Comparator sets being longer
than strictly necessary.  This reduces performance of methods that
iterate over ranges repeatedly (for example, `intersects` and `subset`),
and leads to some confusing toString output like turning `x || * || X`
into `||||` instead of `*`.

- If any simple range in the set contains the null set <0.0.0-0, then
  the entire simple range is the null set. `2.x <0.0.0-0` is the same as
  just `<0.0.0-0`.  (This is used for `>*` and `<*`, which cannot match
  anything.)
- Ensure that a given Comparator will only occur once within each simple
  range set.  `2.3.x ^2.3` doesn't need to include `>=2.3.0` more than
  once.
- If a simple range set contains more than one comparator, remove any `*`
  comparators.  `* >=2.3.4` is the same as just `>=2.3.4`.  This was
  already being done in the cast to a string, but some `ANY` Comparators
  would be left behind in the set used for matching.
- If a Range set contains the simple range `*`, then drop any other
  simple ranges in the set. `* || 2.x` is the same as `*`.

There's still some unnecessary comparators in there.  For example, the
range `2.3 ^2.3.4` parses to `>=2.3.0 <2.4.0-0 >=2.3.4 <3.0.0-0`.  Of
course, anything that is `<2.4.0-0` is also `<3.0.0-0`, and anything
that is `>=2.3.4` is also `>=2.3.0`, so the `<3.0.0-0` and `>=2.3.0`
Comparators are not necessary.  But simplifying those out would be a bit
more work.

To do that, we could walk the set of Comparators checking to see if they
are a subset of any other Comparators in the list, and if so, removing
them.  The subset check would not have to be a full Range.subset(); we
could just see if the gtlt points in the same direction, and if one
semver is greater than the other.  It's an O(n^2) operation, but one on
typically very small n.

PR-URL: #324
Credit: @isaacs
Close: #324
This also enforces our strict 1:1 mapping from tests to the system under test.
@pull pull bot added the ⤵️ pull label Jul 9, 2020
isaacs and others added 11 commits December 1, 2020 10:58
This yields about a 10-20% speed improvement to a lot of common npm
operations that spend most of their CPU time parsing a relatively small
set of dependency ranges.

It does mean that one `range.set` may contain the same Comparator
objects as another range with the same sub-range.  That was technically
already possible, due to the `Comparator.ANY` magic range, but it did
require a bit of tweaking in the `subset` function, which is also now
a bit faster when calculating subsets for ranges that are partly or
entirely identical.
PR-URL: #339
Credit: @jsoref
Close: #339
Reviewed-by: @isaacs
Patch for issue #340

EDIT(@isaacs): updated to make it not break other stuff, and added test.

PR-URL: #341
Credit: @alfredsgenkins
Close: #341
Reviewed-by: @isaacs
Should've been added for range memoization, missed because dev-dep
Adds short-circuit check if superset is `*`.

PR-URL: #375
Credit: @jameschensmith
Close: #375
Reviewed-by: @isaacs
An "ANY" range (ie, `""`, `*`, etc.) does not include prerelease
versions except when `includePrerelease` flag is set.

Also, merely looking at the max/min boundaries of any ranges ignores the
fact that the sub range maybe including prerelease versions that are
excluded from the super range.  For example, `>=1.2.3-pre.0` is _not_ a
subset of `>=1.0.0`, because it inludes `1.2.3-pre.0`, `1.2.3-pre.1`,
and so on.

PR-URL: #377
Credit: @isaacs
Close: #377
Reviewed-by: @wraithgar
@wraithgar wraithgar deleted the branch fisker:master September 21, 2021 18:15
@wraithgar wraithgar deleted the master branch September 21, 2021 18:15
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants