| Index: node_modules/vulcanize/node_modules/update-notifier/node_modules/semver-diff/node_modules/semver/README.md
|
| diff --git a/node_modules/vulcanize/node_modules/update-notifier/node_modules/semver-diff/node_modules/semver/README.md b/node_modules/vulcanize/node_modules/update-notifier/node_modules/semver-diff/node_modules/semver/README.md
|
| new file mode 100644
|
| index 0000000000000000000000000000000000000000..5e2862f1ada8e5d5292ef5cd5a3f6dd8b5aed150
|
| --- /dev/null
|
| +++ b/node_modules/vulcanize/node_modules/update-notifier/node_modules/semver-diff/node_modules/semver/README.md
|
| @@ -0,0 +1,297 @@
|
| +semver(1) -- The semantic versioner for npm
|
| +===========================================
|
| +
|
| +## Usage
|
| +
|
| + $ npm install semver
|
| +
|
| + semver.valid('1.2.3') // '1.2.3'
|
| + semver.valid('a.b.c') // null
|
| + semver.clean(' =v1.2.3 ') // '1.2.3'
|
| + semver.satisfies('1.2.3', '1.x || >=2.5.0 || 5.0.0 - 7.2.3') // true
|
| + semver.gt('1.2.3', '9.8.7') // false
|
| + semver.lt('1.2.3', '9.8.7') // true
|
| +
|
| +As a command-line utility:
|
| +
|
| + $ semver -h
|
| +
|
| + Usage: semver <version> [<version> [...]] [-r <range> | -i <inc> | --preid <identifier> | -l | -rv]
|
| + Test if version(s) satisfy the supplied range(s), and sort them.
|
| +
|
| + Multiple versions or ranges may be supplied, unless increment
|
| + option is specified. In that case, only a single version may
|
| + be used, and it is incremented by the specified level
|
| +
|
| + Program exits successfully if any valid version satisfies
|
| + all supplied ranges, and prints all satisfying versions.
|
| +
|
| + If no versions are valid, or ranges are not satisfied,
|
| + then exits failure.
|
| +
|
| + Versions are printed in ascending order, so supplying
|
| + multiple versions to the utility will just sort them.
|
| +
|
| +## Versions
|
| +
|
| +A "version" is described by the `v2.0.0` specification found at
|
| +<http://semver.org/>.
|
| +
|
| +A leading `"="` or `"v"` character is stripped off and ignored.
|
| +
|
| +## Ranges
|
| +
|
| +A `version range` is a set of `comparators` which specify versions
|
| +that satisfy the range.
|
| +
|
| +A `comparator` is composed of an `operator` and a `version`. The set
|
| +of primitive `operators` is:
|
| +
|
| +* `<` Less than
|
| +* `<=` Less than or equal to
|
| +* `>` Greater than
|
| +* `>=` Greater than or equal to
|
| +* `=` Equal. If no operator is specified, then equality is assumed,
|
| + so this operator is optional, but MAY be included.
|
| +
|
| +For example, the comparator `>=1.2.7` would match the versions
|
| +`1.2.7`, `1.2.8`, `2.5.3`, and `1.3.9`, but not the versions `1.2.6`
|
| +or `1.1.0`.
|
| +
|
| +Comparators can be joined by whitespace to form a `comparator set`,
|
| +which is satisfied by the **intersection** of all of the comparators
|
| +it includes.
|
| +
|
| +A range is composed of one or more comparator sets, joined by `||`. A
|
| +version matches a range if and only if every comparator in at least
|
| +one of the `||`-separated comparator sets is satisfied by the version.
|
| +
|
| +For example, the range `>=1.2.7 <1.3.0` would match the versions
|
| +`1.2.7`, `1.2.8`, and `1.2.99`, but not the versions `1.2.6`, `1.3.0`,
|
| +or `1.1.0`.
|
| +
|
| +The range `1.2.7 || >=1.2.9 <2.0.0` would match the versions `1.2.7`,
|
| +`1.2.9`, and `1.4.6`, but not the versions `1.2.8` or `2.0.0`.
|
| +
|
| +### Prerelease Tags
|
| +
|
| +If a version has a prerelease tag (for example, `1.2.3-alpha.3`) then
|
| +it will only be allowed to satisfy comparator sets if at least one
|
| +comparator with the same `[major, minor, patch]` tuple also has a
|
| +prerelease tag.
|
| +
|
| +For example, the range `>1.2.3-alpha.3` would be allowed to match the
|
| +version `1.2.3-alpha.7`, but it would *not* be satisfied by
|
| +`3.4.5-alpha.9`, even though `3.4.5-alpha.9` is technically "greater
|
| +than" `1.2.3-alpha.3` according to the SemVer sort rules. The version
|
| +range only accepts prerelease tags on the `1.2.3` version. The
|
| +version `3.4.5` *would* satisfy the range, because it does not have a
|
| +prerelease flag, and `3.4.5` is greater than `1.2.3-alpha.7`.
|
| +
|
| +The purpose for this behavior is twofold. First, prerelease versions
|
| +frequently are updated very quickly, and contain many breaking changes
|
| +that are (by the author's design) not yet fit for public consumption.
|
| +Therefore, by default, they are excluded from range matching
|
| +semantics.
|
| +
|
| +Second, a user who has opted into using a prerelease version has
|
| +clearly indicated the intent to use *that specific* set of
|
| +alpha/beta/rc versions. By including a prerelease tag in the range,
|
| +the user is indicating that they are aware of the risk. However, it
|
| +is still not appropriate to assume that they have opted into taking a
|
| +similar risk on the *next* set of prerelease versions.
|
| +
|
| +#### Prerelease Identifiers
|
| +
|
| +The method `.inc` takes an additional `identifier` string argument that
|
| +will append the value of the string as a prerelease identifier:
|
| +
|
| +````javascript
|
| +> semver.inc('1.2.3', 'pre', 'beta')
|
| +'1.2.4-beta.0'
|
| +```
|
| +
|
| +command-line example:
|
| +
|
| +```shell
|
| +$ semver 1.2.3 -i prerelease --preid beta
|
| +1.2.4-beta.0
|
| +```
|
| +
|
| +Which then can be used to increment further:
|
| +
|
| +```shell
|
| +$ semver 1.2.4-beta.0 -i prerelease
|
| +1.2.4-beta.1
|
| +```
|
| +
|
| +### Advanced Range Syntax
|
| +
|
| +Advanced range syntax desugars to primitive comparators in
|
| +deterministic ways.
|
| +
|
| +Advanced ranges may be combined in the same way as primitive
|
| +comparators using white space or `||`.
|
| +
|
| +#### Hyphen Ranges `X.Y.Z - A.B.C`
|
| +
|
| +Specifies an inclusive set.
|
| +
|
| +* `1.2.3 - 2.3.4` := `>=1.2.3 <=2.3.4`
|
| +
|
| +If a partial version is provided as the first version in the inclusive
|
| +range, then the missing pieces are replaced with zeroes.
|
| +
|
| +* `1.2 - 2.3.4` := `>=1.2.0 <=2.3.4`
|
| +
|
| +If a partial version is provided as the second version in the
|
| +inclusive range, then all versions that start with the supplied parts
|
| +of the tuple are accepted, but nothing that would be greater than the
|
| +provided tuple parts.
|
| +
|
| +* `1.2.3 - 2.3` := `>=1.2.3 <2.4.0`
|
| +* `1.2.3 - 2` := `>=1.2.3 <3.0.0`
|
| +
|
| +#### X-Ranges `1.2.x` `1.X` `1.2.*` `*`
|
| +
|
| +Any of `X`, `x`, or `*` may be used to "stand in" for one of the
|
| +numeric values in the `[major, minor, patch]` tuple.
|
| +
|
| +* `*` := `>=0.0.0` (Any version satisfies)
|
| +* `1.x` := `>=1.0.0 <2.0.0` (Matching major version)
|
| +* `1.2.x` := `>=1.2.0 <1.3.0` (Matching major and minor versions)
|
| +
|
| +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`
|
| +* `1.2` := `1.2.x` := `>=1.2.0 <1.3.0`
|
| +
|
| +#### Tilde Ranges `~1.2.3` `~1.2` `~1`
|
| +
|
| +Allows patch-level changes if a minor version is specified on the
|
| +comparator. Allows minor-level changes if not.
|
| +
|
| +* `~1.2.3` := `>=1.2.3 <1.(2+1).0` := `>=1.2.3 <1.3.0`
|
| +* `~1.2` := `>=1.2.0 <1.(2+1).0` := `>=1.2.0 <1.3.0` (Same as `1.2.x`)
|
| +* `~1` := `>=1.0.0 <(1+1).0.0` := `>=1.0.0 <2.0.0` (Same as `1.x`)
|
| +* `~0.2.3` := `>=0.2.3 <0.(2+1).0` := `>=0.2.3 <0.3.0`
|
| +* `~0.2` := `>=0.2.0 <0.(2+1).0` := `>=0.2.0 <0.3.0` (Same as `0.2.x`)
|
| +* `~0` := `>=0.0.0 <(0+1).0.0` := `>=0.0.0 <1.0.0` (Same as `0.x`)
|
| +* `~1.2.3-beta.2` := `>=1.2.3-beta.2 <1.3.0` Note that prereleases in
|
| + the `1.2.3` version will be allowed, if they are greater than or
|
| + equal to `beta.2`. So, `1.2.3-beta.4` would be allowed, but
|
| + `1.2.4-beta.2` would not, because it is a prerelease of a
|
| + different `[major, minor, patch]` tuple.
|
| +
|
| +#### Caret Ranges `^1.2.3` `^0.2.5` `^0.0.4`
|
| +
|
| +Allows changes that do not modify the left-most non-zero digit in the
|
| +`[major, minor, patch]` tuple. In other words, this allows patch and
|
| +minor updates for versions `1.0.0` and above, patch updates for
|
| +versions `0.X >=0.1.0`, and *no* updates for versions `0.0.X`.
|
| +
|
| +Many authors treat a `0.x` version as if the `x` were the major
|
| +"breaking-change" indicator.
|
| +
|
| +Caret ranges are ideal when an author may make breaking changes
|
| +between `0.2.4` and `0.3.0` releases, which is a common practice.
|
| +However, it presumes that there will *not* be breaking changes between
|
| +`0.2.4` and `0.2.5`. It allows for changes that are presumed to be
|
| +additive (but non-breaking), according to commonly observed practices.
|
| +
|
| +* `^1.2.3` := `>=1.2.3 <2.0.0`
|
| +* `^0.2.3` := `>=0.2.3 <0.3.0`
|
| +* `^0.0.3` := `>=0.0.3 <0.0.4`
|
| +* `^1.2.3-beta.2` := `>=1.2.3-beta.2 <2.0.0` Note that prereleases in
|
| + the `1.2.3` version will be allowed, if they are greater than or
|
| + equal to `beta.2`. So, `1.2.3-beta.4` would be allowed, but
|
| + `1.2.4-beta.2` would not, because it is a prerelease of a
|
| + different `[major, minor, patch]` tuple.
|
| +* `^0.0.3-beta` := `>=0.0.3-beta <0.0.4` Note that prereleases in the
|
| + `0.0.3` version *only* will be allowed, if they are greater than or
|
| + equal to `beta`. So, `0.0.3-pr.2` would be allowed.
|
| +
|
| +When parsing caret ranges, a missing `patch` value desugars to the
|
| +number `0`, but will allow flexibility within that value, even if the
|
| +major and minor versions are both `0`.
|
| +
|
| +* `^1.2.x` := `>=1.2.0 <2.0.0`
|
| +* `^0.0.x` := `>=0.0.0 <0.1.0`
|
| +* `^0.0` := `>=0.0.0 <0.1.0`
|
| +
|
| +A missing `minor` and `patch` values will desugar to zero, but also
|
| +allow flexibility within those values, even if the major version is
|
| +zero.
|
| +
|
| +* `^1.x` := `>=1.0.0 <2.0.0`
|
| +* `^0.x` := `>=0.0.0 <1.0.0`
|
| +
|
| +## Functions
|
| +
|
| +All methods and classes take a final `loose` boolean argument that, if
|
| +true, will be more forgiving about not-quite-valid semver strings.
|
| +The resulting output will always be 100% strict, of course.
|
| +
|
| +Strict-mode Comparators and Ranges will be strict about the SemVer
|
| +strings that they parse.
|
| +
|
| +* `valid(v)`: Return the parsed version, or null if it's not valid.
|
| +* `inc(v, release)`: Return the version incremented by the release
|
| + type (`major`, `premajor`, `minor`, `preminor`, `patch`,
|
| + `prepatch`, or `prerelease`), or null if it's not valid
|
| + * `premajor` in one call will bump the version up to the next major
|
| + version and down to a prerelease of that major version.
|
| + `preminor`, and `prepatch` work the same way.
|
| + * If called from a non-prerelease version, the `prerelease` will work the
|
| + same as `prepatch`. It increments the patch version, then makes a
|
| + prerelease. If the input version is already a prerelease it simply
|
| + increments it.
|
| +
|
| +### Comparison
|
| +
|
| +* `gt(v1, v2)`: `v1 > v2`
|
| +* `gte(v1, v2)`: `v1 >= v2`
|
| +* `lt(v1, v2)`: `v1 < v2`
|
| +* `lte(v1, v2)`: `v1 <= v2`
|
| +* `eq(v1, v2)`: `v1 == v2` This is true if they're logically equivalent,
|
| + even if they're not the exact same string. You already know how to
|
| + compare strings.
|
| +* `neq(v1, v2)`: `v1 != v2` The opposite of `eq`.
|
| +* `cmp(v1, comparator, v2)`: Pass in a comparison string, and it'll call
|
| + the corresponding function above. `"==="` and `"!=="` do simple
|
| + string comparison, but are included for completeness. Throws if an
|
| + invalid comparison string is provided.
|
| +* `compare(v1, v2)`: Return `0` if `v1 == v2`, or `1` if `v1` is greater, or `-1` if
|
| + `v2` is greater. Sorts in ascending order if passed to `Array.sort()`.
|
| +* `rcompare(v1, v2)`: The reverse of compare. Sorts an array of versions
|
| + in descending order when passed to `Array.sort()`.
|
| +
|
| +
|
| +### Ranges
|
| +
|
| +* `validRange(range)`: Return the valid range or null if it's not valid
|
| +* `satisfies(version, range)`: Return true if the version satisfies the
|
| + range.
|
| +* `maxSatisfying(versions, range)`: Return the highest version in the list
|
| + that satisfies the range, or `null` if none of them do.
|
| +* `gtr(version, range)`: Return `true` if version is greater than all the
|
| + versions possible in the range.
|
| +* `ltr(version, range)`: Return `true` if version is less than all the
|
| + versions possible in the range.
|
| +* `outside(version, range, hilo)`: Return true if the version is outside
|
| + the bounds of the range in either the high or low direction. The
|
| + `hilo` argument must be either the string `'>'` or `'<'`. (This is
|
| + the function called by `gtr` and `ltr`.)
|
| +
|
| +Note that, since ranges may be non-contiguous, a version might not be
|
| +greater than a range, less than a range, *or* satisfy a range! For
|
| +example, the range `1.2 <1.2.9 || >2.0.0` would have a hole from `1.2.9`
|
| +until `2.0.0`, so the version `1.2.10` would not be greater than the
|
| +range (because `2.0.1` satisfies, which is higher), nor less than the
|
| +range (since `1.2.8` satisfies, which is lower), and it also does not
|
| +satisfy the range.
|
| +
|
| +If you want to know if a version satisfies or does not satisfy a
|
| +range, use the `satisfies(version, range)` function.
|
|
|