root / HServer / 00.Server / 00.Program / node_modules / semver / README.md
이력 | 보기 | 이력해설 | 다운로드 (14.3 KB)
1 |
semver(1) -- The semantic versioner for npm |
---|---|
2 |
=========================================== |
3 |
|
4 |
## Install |
5 |
|
6 |
```bash |
7 |
npm install --save semver |
8 |
```` |
9 |
|
10 |
## Usage |
11 |
|
12 |
As a node module: |
13 |
|
14 |
```js |
15 |
const semver = require('semver') |
16 |
|
17 |
semver.valid('1.2.3') // '1.2.3' |
18 |
semver.valid('a.b.c') // null |
19 |
semver.clean(' =v1.2.3 ') // '1.2.3' |
20 |
semver.satisfies('1.2.3', '1.x || >=2.5.0 || 5.0.0 - 7.2.3') // true |
21 |
semver.gt('1.2.3', '9.8.7') // false |
22 |
semver.lt('1.2.3', '9.8.7') // true |
23 |
semver.valid(semver.coerce('v2')) // '2.0.0' |
24 |
semver.valid(semver.coerce('42.6.7.9.3-alpha')) // '42.6.7' |
25 |
``` |
26 |
|
27 |
As a command-line utility: |
28 |
|
29 |
``` |
30 |
$ semver -h |
31 |
|
32 |
SemVer 5.3.0 |
33 |
|
34 |
A JavaScript implementation of the http://semver.org/ specification |
35 |
Copyright Isaac Z. Schlueter |
36 |
|
37 |
Usage: semver [options] <version> [<version> [...]] |
38 |
Prints valid versions sorted by SemVer precedence |
39 |
|
40 |
Options: |
41 |
-r --range <range> |
42 |
Print versions that match the specified range. |
43 |
|
44 |
-i --increment [<level>] |
45 |
Increment a version by the specified level. Level can |
46 |
be one of: major, minor, patch, premajor, preminor, |
47 |
prepatch, or prerelease. Default level is 'patch'. |
48 |
Only one version may be specified. |
49 |
|
50 |
--preid <identifier> |
51 |
Identifier to be used to prefix premajor, preminor, |
52 |
prepatch or prerelease version increments. |
53 |
|
54 |
-l --loose |
55 |
Interpret versions and ranges loosely |
56 |
|
57 |
-c --coerce |
58 |
Coerce a string into SemVer if possible |
59 |
(does not imply --loose) |
60 |
|
61 |
Program exits successfully if any valid version satisfies |
62 |
all supplied ranges, and prints all satisfying versions. |
63 |
|
64 |
If no satisfying versions are found, then exits failure. |
65 |
|
66 |
Versions are printed in ascending order, so supplying |
67 |
multiple versions to the utility will just sort them. |
68 |
``` |
69 |
|
70 |
## Versions |
71 |
|
72 |
A "version" is described by the `v2.0.0` specification found at |
73 |
<http://semver.org/>. |
74 |
|
75 |
A leading `"="` or `"v"` character is stripped off and ignored. |
76 |
|
77 |
## Ranges |
78 |
|
79 |
A `version range` is a set of `comparators` which specify versions |
80 |
that satisfy the range. |
81 |
|
82 |
A `comparator` is composed of an `operator` and a `version`. The set |
83 |
of primitive `operators` is: |
84 |
|
85 |
* `<` Less than |
86 |
* `<=` Less than or equal to |
87 |
* `>` Greater than |
88 |
* `>=` Greater than or equal to |
89 |
* `=` Equal. If no operator is specified, then equality is assumed, |
90 |
so this operator is optional, but MAY be included. |
91 |
|
92 |
For example, the comparator `>=1.2.7` would match the versions |
93 |
`1.2.7`, `1.2.8`, `2.5.3`, and `1.3.9`, but not the versions `1.2.6` |
94 |
or `1.1.0`. |
95 |
|
96 |
Comparators can be joined by whitespace to form a `comparator set`, |
97 |
which is satisfied by the **intersection** of all of the comparators |
98 |
it includes. |
99 |
|
100 |
A range is composed of one or more comparator sets, joined by `||`. A |
101 |
version matches a range if and only if every comparator in at least |
102 |
one of the `||`-separated comparator sets is satisfied by the version. |
103 |
|
104 |
For example, the range `>=1.2.7 <1.3.0` would match the versions |
105 |
`1.2.7`, `1.2.8`, and `1.2.99`, but not the versions `1.2.6`, `1.3.0`, |
106 |
or `1.1.0`. |
107 |
|
108 |
The range `1.2.7 || >=1.2.9 <2.0.0` would match the versions `1.2.7`, |
109 |
`1.2.9`, and `1.4.6`, but not the versions `1.2.8` or `2.0.0`. |
110 |
|
111 |
### Prerelease Tags |
112 |
|
113 |
If a version has a prerelease tag (for example, `1.2.3-alpha.3`) then |
114 |
it will only be allowed to satisfy comparator sets if at least one |
115 |
comparator with the same `[major, minor, patch]` tuple also has a |
116 |
prerelease tag. |
117 |
|
118 |
For example, the range `>1.2.3-alpha.3` would be allowed to match the |
119 |
version `1.2.3-alpha.7`, but it would *not* be satisfied by |
120 |
`3.4.5-alpha.9`, even though `3.4.5-alpha.9` is technically "greater |
121 |
than" `1.2.3-alpha.3` according to the SemVer sort rules. The version |
122 |
range only accepts prerelease tags on the `1.2.3` version. The |
123 |
version `3.4.5` *would* satisfy the range, because it does not have a |
124 |
prerelease flag, and `3.4.5` is greater than `1.2.3-alpha.7`. |
125 |
|
126 |
The purpose for this behavior is twofold. First, prerelease versions |
127 |
frequently are updated very quickly, and contain many breaking changes |
128 |
that are (by the author's design) not yet fit for public consumption. |
129 |
Therefore, by default, they are excluded from range matching |
130 |
semantics. |
131 |
|
132 |
Second, a user who has opted into using a prerelease version has |
133 |
clearly indicated the intent to use *that specific* set of |
134 |
alpha/beta/rc versions. By including a prerelease tag in the range, |
135 |
the user is indicating that they are aware of the risk. However, it |
136 |
is still not appropriate to assume that they have opted into taking a |
137 |
similar risk on the *next* set of prerelease versions. |
138 |
|
139 |
#### Prerelease Identifiers |
140 |
|
141 |
The method `.inc` takes an additional `identifier` string argument that |
142 |
will append the value of the string as a prerelease identifier: |
143 |
|
144 |
```javascript |
145 |
semver.inc('1.2.3', 'prerelease', 'beta') |
146 |
// '1.2.4-beta.0' |
147 |
``` |
148 |
|
149 |
command-line example: |
150 |
|
151 |
```bash |
152 |
$ semver 1.2.3 -i prerelease --preid beta |
153 |
1.2.4-beta.0 |
154 |
``` |
155 |
|
156 |
Which then can be used to increment further: |
157 |
|
158 |
```bash |
159 |
$ semver 1.2.4-beta.0 -i prerelease |
160 |
1.2.4-beta.1 |
161 |
``` |
162 |
|
163 |
### Advanced Range Syntax |
164 |
|
165 |
Advanced range syntax desugars to primitive comparators in |
166 |
deterministic ways. |
167 |
|
168 |
Advanced ranges may be combined in the same way as primitive |
169 |
comparators using white space or `||`. |
170 |
|
171 |
#### Hyphen Ranges `X.Y.Z - A.B.C` |
172 |
|
173 |
Specifies an inclusive set. |
174 |
|
175 |
* `1.2.3 - 2.3.4` := `>=1.2.3 <=2.3.4` |
176 |
|
177 |
If a partial version is provided as the first version in the inclusive |
178 |
range, then the missing pieces are replaced with zeroes. |
179 |
|
180 |
* `1.2 - 2.3.4` := `>=1.2.0 <=2.3.4` |
181 |
|
182 |
If a partial version is provided as the second version in the |
183 |
inclusive range, then all versions that start with the supplied parts |
184 |
of the tuple are accepted, but nothing that would be greater than the |
185 |
provided tuple parts. |
186 |
|
187 |
* `1.2.3 - 2.3` := `>=1.2.3 <2.4.0` |
188 |
* `1.2.3 - 2` := `>=1.2.3 <3.0.0` |
189 |
|
190 |
#### X-Ranges `1.2.x` `1.X` `1.2.*` `*` |
191 |
|
192 |
Any of `X`, `x`, or `*` may be used to "stand in" for one of the |
193 |
numeric values in the `[major, minor, patch]` tuple. |
194 |
|
195 |
* `*` := `>=0.0.0` (Any version satisfies) |
196 |
* `1.x` := `>=1.0.0 <2.0.0` (Matching major version) |
197 |
* `1.2.x` := `>=1.2.0 <1.3.0` (Matching major and minor versions) |
198 |
|
199 |
A partial version range is treated as an X-Range, so the special |
200 |
character is in fact optional. |
201 |
|
202 |
* `""` (empty string) := `*` := `>=0.0.0` |
203 |
* `1` := `1.x.x` := `>=1.0.0 <2.0.0` |
204 |
* `1.2` := `1.2.x` := `>=1.2.0 <1.3.0` |
205 |
|
206 |
#### Tilde Ranges `~1.2.3` `~1.2` `~1` |
207 |
|
208 |
Allows patch-level changes if a minor version is specified on the |
209 |
comparator. Allows minor-level changes if not. |
210 |
|
211 |
* `~1.2.3` := `>=1.2.3 <1.(2+1).0` := `>=1.2.3 <1.3.0` |
212 |
* `~1.2` := `>=1.2.0 <1.(2+1).0` := `>=1.2.0 <1.3.0` (Same as `1.2.x`) |
213 |
* `~1` := `>=1.0.0 <(1+1).0.0` := `>=1.0.0 <2.0.0` (Same as `1.x`) |
214 |
* `~0.2.3` := `>=0.2.3 <0.(2+1).0` := `>=0.2.3 <0.3.0` |
215 |
* `~0.2` := `>=0.2.0 <0.(2+1).0` := `>=0.2.0 <0.3.0` (Same as `0.2.x`) |
216 |
* `~0` := `>=0.0.0 <(0+1).0.0` := `>=0.0.0 <1.0.0` (Same as `0.x`) |
217 |
* `~1.2.3-beta.2` := `>=1.2.3-beta.2 <1.3.0` Note that prereleases in |
218 |
the `1.2.3` version will be allowed, if they are greater than or |
219 |
equal to `beta.2`. So, `1.2.3-beta.4` would be allowed, but |
220 |
`1.2.4-beta.2` would not, because it is a prerelease of a |
221 |
different `[major, minor, patch]` tuple. |
222 |
|
223 |
#### Caret Ranges `^1.2.3` `^0.2.5` `^0.0.4` |
224 |
|
225 |
Allows changes that do not modify the left-most non-zero digit in the |
226 |
`[major, minor, patch]` tuple. In other words, this allows patch and |
227 |
minor updates for versions `1.0.0` and above, patch updates for |
228 |
versions `0.X >=0.1.0`, and *no* updates for versions `0.0.X`. |
229 |
|
230 |
Many authors treat a `0.x` version as if the `x` were the major |
231 |
"breaking-change" indicator. |
232 |
|
233 |
Caret ranges are ideal when an author may make breaking changes |
234 |
between `0.2.4` and `0.3.0` releases, which is a common practice. |
235 |
However, it presumes that there will *not* be breaking changes between |
236 |
`0.2.4` and `0.2.5`. It allows for changes that are presumed to be |
237 |
additive (but non-breaking), according to commonly observed practices. |
238 |
|
239 |
* `^1.2.3` := `>=1.2.3 <2.0.0` |
240 |
* `^0.2.3` := `>=0.2.3 <0.3.0` |
241 |
* `^0.0.3` := `>=0.0.3 <0.0.4` |
242 |
* `^1.2.3-beta.2` := `>=1.2.3-beta.2 <2.0.0` Note that prereleases in |
243 |
the `1.2.3` version will be allowed, if they are greater than or |
244 |
equal to `beta.2`. So, `1.2.3-beta.4` would be allowed, but |
245 |
`1.2.4-beta.2` would not, because it is a prerelease of a |
246 |
different `[major, minor, patch]` tuple. |
247 |
* `^0.0.3-beta` := `>=0.0.3-beta <0.0.4` Note that prereleases in the |
248 |
`0.0.3` version *only* will be allowed, if they are greater than or |
249 |
equal to `beta`. So, `0.0.3-pr.2` would be allowed. |
250 |
|
251 |
When parsing caret ranges, a missing `patch` value desugars to the |
252 |
number `0`, but will allow flexibility within that value, even if the |
253 |
major and minor versions are both `0`. |
254 |
|
255 |
* `^1.2.x` := `>=1.2.0 <2.0.0` |
256 |
* `^0.0.x` := `>=0.0.0 <0.1.0` |
257 |
* `^0.0` := `>=0.0.0 <0.1.0` |
258 |
|
259 |
A missing `minor` and `patch` values will desugar to zero, but also |
260 |
allow flexibility within those values, even if the major version is |
261 |
zero. |
262 |
|
263 |
* `^1.x` := `>=1.0.0 <2.0.0` |
264 |
* `^0.x` := `>=0.0.0 <1.0.0` |
265 |
|
266 |
### Range Grammar |
267 |
|
268 |
Putting all this together, here is a Backus-Naur grammar for ranges, |
269 |
for the benefit of parser authors: |
270 |
|
271 |
```bnf |
272 |
range-set ::= range ( logical-or range ) * |
273 |
logical-or ::= ( ' ' ) * '||' ( ' ' ) * |
274 |
range ::= hyphen | simple ( ' ' simple ) * | '' |
275 |
hyphen ::= partial ' - ' partial |
276 |
simple ::= primitive | partial | tilde | caret |
277 |
primitive ::= ( '<' | '>' | '>=' | '<=' | '=' | ) partial |
278 |
partial ::= xr ( '.' xr ( '.' xr qualifier ? )? )? |
279 |
xr ::= 'x' | 'X' | '*' | nr |
280 |
nr ::= '0' | ['1'-'9'] ( ['0'-'9'] ) * |
281 |
tilde ::= '~' partial |
282 |
caret ::= '^' partial |
283 |
qualifier ::= ( '-' pre )? ( '+' build )? |
284 |
pre ::= parts |
285 |
build ::= parts |
286 |
parts ::= part ( '.' part ) * |
287 |
part ::= nr | [-0-9A-Za-z]+ |
288 |
``` |
289 |
|
290 |
## Functions |
291 |
|
292 |
All methods and classes take a final `loose` boolean argument that, if |
293 |
true, will be more forgiving about not-quite-valid semver strings. |
294 |
The resulting output will always be 100% strict, of course. |
295 |
|
296 |
Strict-mode Comparators and Ranges will be strict about the SemVer |
297 |
strings that they parse. |
298 |
|
299 |
* `valid(v)`: Return the parsed version, or null if it's not valid. |
300 |
* `inc(v, release)`: Return the version incremented by the release |
301 |
type (`major`, `premajor`, `minor`, `preminor`, `patch`, |
302 |
`prepatch`, or `prerelease`), or null if it's not valid |
303 |
* `premajor` in one call will bump the version up to the next major |
304 |
version and down to a prerelease of that major version. |
305 |
`preminor`, and `prepatch` work the same way. |
306 |
* If called from a non-prerelease version, the `prerelease` will work the |
307 |
same as `prepatch`. It increments the patch version, then makes a |
308 |
prerelease. If the input version is already a prerelease it simply |
309 |
increments it. |
310 |
* `prerelease(v)`: Returns an array of prerelease components, or null |
311 |
if none exist. Example: `prerelease('1.2.3-alpha.1') -> ['alpha', 1]` |
312 |
* `major(v)`: Return the major version number. |
313 |
* `minor(v)`: Return the minor version number. |
314 |
* `patch(v)`: Return the patch version number. |
315 |
* `intersects(r1, r2, loose)`: Return true if the two supplied ranges |
316 |
or comparators intersect. |
317 |
|
318 |
### Comparison |
319 |
|
320 |
* `gt(v1, v2)`: `v1 > v2` |
321 |
* `gte(v1, v2)`: `v1 >= v2` |
322 |
* `lt(v1, v2)`: `v1 < v2` |
323 |
* `lte(v1, v2)`: `v1 <= v2` |
324 |
* `eq(v1, v2)`: `v1 == v2` This is true if they're logically equivalent, |
325 |
even if they're not the exact same string. You already know how to |
326 |
compare strings. |
327 |
* `neq(v1, v2)`: `v1 != v2` The opposite of `eq`. |
328 |
* `cmp(v1, comparator, v2)`: Pass in a comparison string, and it'll call |
329 |
the corresponding function above. `"==="` and `"!=="` do simple |
330 |
string comparison, but are included for completeness. Throws if an |
331 |
invalid comparison string is provided. |
332 |
* `compare(v1, v2)`: Return `0` if `v1 == v2`, or `1` if `v1` is greater, or `-1` if |
333 |
`v2` is greater. Sorts in ascending order if passed to `Array.sort()`. |
334 |
* `rcompare(v1, v2)`: The reverse of compare. Sorts an array of versions |
335 |
in descending order when passed to `Array.sort()`. |
336 |
* `diff(v1, v2)`: Returns difference between two versions by the release type |
337 |
(`major`, `premajor`, `minor`, `preminor`, `patch`, `prepatch`, or `prerelease`), |
338 |
or null if the versions are the same. |
339 |
|
340 |
### Comparators |
341 |
|
342 |
* `intersects(comparator)`: Return true if the comparators intersect |
343 |
|
344 |
### Ranges |
345 |
|
346 |
* `validRange(range)`: Return the valid range or null if it's not valid |
347 |
* `satisfies(version, range)`: Return true if the version satisfies the |
348 |
range. |
349 |
* `maxSatisfying(versions, range)`: Return the highest version in the list |
350 |
that satisfies the range, or `null` if none of them do. |
351 |
* `minSatisfying(versions, range)`: Return the lowest version in the list |
352 |
that satisfies the range, or `null` if none of them do. |
353 |
* `gtr(version, range)`: Return `true` if version is greater than all the |
354 |
versions possible in the range. |
355 |
* `ltr(version, range)`: Return `true` if version is less than all the |
356 |
versions possible in the range. |
357 |
* `outside(version, range, hilo)`: Return true if the version is outside |
358 |
the bounds of the range in either the high or low direction. The |
359 |
`hilo` argument must be either the string `'>'` or `'<'`. (This is |
360 |
the function called by `gtr` and `ltr`.) |
361 |
* `intersects(range)`: Return true if any of the ranges comparators intersect |
362 |
|
363 |
Note that, since ranges may be non-contiguous, a version might not be |
364 |
greater than a range, less than a range, *or* satisfy a range! For |
365 |
example, the range `1.2 <1.2.9 || >2.0.0` would have a hole from `1.2.9` |
366 |
until `2.0.0`, so the version `1.2.10` would not be greater than the |
367 |
range (because `2.0.1` satisfies, which is higher), nor less than the |
368 |
range (since `1.2.8` satisfies, which is lower), and it also does not |
369 |
satisfy the range. |
370 |
|
371 |
If you want to know if a version satisfies or does not satisfy a |
372 |
range, use the `satisfies(version, range)` function. |
373 |
|
374 |
### Coercion |
375 |
|
376 |
* `coerce(version)`: Coerces a string to semver if possible |
377 |
|
378 |
This aims to provide a very forgiving translation of a non-semver |
379 |
string to semver. It looks for the first digit in a string, and |
380 |
consumes all remaining characters which satisfy at least a partial semver |
381 |
(e.g., `1`, `1.2`, `1.2.3`) up to the max permitted length (256 characters). |
382 |
Longer versions are simply truncated (`4.6.3.9.2-alpha2` becomes `4.6.3`). |
383 |
All surrounding text is simply ignored (`v3.4 replaces v3.3.1` becomes `3.4.0`). |
384 |
Only text which lacks digits will fail coercion (`version one` is not valid). |
385 |
The maximum length for any semver component considered for coercion is 16 characters; |
386 |
longer components will be ignored (`10000000000000000.4.7.4` becomes `4.7.4`). |
387 |
The maximum value for any semver component is `Integer.MAX_SAFE_INTEGER || (2**53 - 1)`; |
388 |
higher value components are invalid (`9999999999999999.4.7.4` is likely invalid). |