Closed
Conversation
48e4cc6 to
499284b
Compare
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.
499284b to
028a2f7
Compare
kellyselden
pushed a commit
to kellyselden/monorepo-next
that referenced
this pull request
Dec 22, 2020
Coming from npm/node-semver#324.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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,
intersectsandsubset),and leads to some confusing toString output like turning
x || * || Xinto
||||instead of*.the entire simple range is the null set.
2.x <0.0.0-0is the same asjust
<0.0.0-0. (This is used for>*and<*, which cannot matchanything.)
range set.
2.3.x ^2.3doesn't need to include>=2.3.0more thanonce.
*comparators.
* >=2.3.4is the same as just>=2.3.4. This wasalready being done in the cast to a string, but some
ANYComparatorswould be left behind in the set used for matching.
*, then drop any othersimple ranges in the set.
* || 2.xis the same as*.There's still some unnecessary comparators in there. For example, the
range
2.3 ^2.3.4parses to>=2.3.0 <2.4.0-0 >=2.3.4 <3.0.0-0. Ofcourse, anything that is
<2.4.0-0is also<3.0.0-0, and anythingthat is
>=2.3.4is also>=2.3.0, so the<3.0.0-0and>=2.3.0Comparators 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.