forked from npm/node-semver
-
-
Notifications
You must be signed in to change notification settings - Fork 0
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
pull
wants to merge
19
commits into
fisker:master
Choose a base branch
from
npm:master
base: master
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Open
Conversation
This file contains 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
PR-URL: #316 Credit: @raphaelzulliger Close: #316 Reviewed-by: @isaacs
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.
PR-URL: #315 Credit: @raphaelzulliger Close: #315 Reviewed-by: @isaacs
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.
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.
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
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.
See Commits and Changes for more details.
Created by pull[bot]. Want to support this open source service? Please star it : )