deno.land / std@0.224.0 / semver / mod.ts

View Documentation
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
// Copyright Isaac Z. Schlueter and Contributors. All rights reserved. ISC license.// Copyright 2018-2024 the Deno authors. All rights reserved. MIT license.// This module is browser compatible.
/** * The semantic version parser. * * Adapted directly from {@link https://github.com/npm/node-semver | semver}. * * ## Versions * * A "version" is described by the `v2.0.0` specification found at * <https://semver.org>. * * A leading `"="` or `"v"` character is stripped off and ignored. * * ## Format * * Semantic versions can be formatted as strings, by default they * are formatted as `full`. Below is a diagram showing the various * formatting options. * * ``` * ┌───── full * ┌───┴───┐ * ├───────── release * ┌───┴───┐ │ * ├───────────── primary * ┌─┴─┐ │ │ * 1.2.3-pre.1+b.1 * │ │ │ └─┬─┘ └┬┘ * │ │ │ │ └── build * │ │ │ └─────── pre * │ │ └─────────── patch * │ └───────────── minor * └─────────────── major * ``` * * ## 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 `.increment` takes an additional `identifier` string argument that * will append the value of the string as a prerelease identifier: * * ```javascript * semver.increment(parse("1.2.3"), "prerelease", "beta"); * // "1.2.4-beta.0" * ``` * * ### Build Metadata * * Build metadata is `.` delimited alpha-numeric string. * When parsing a version it is retained on the `build: string[]` field * of the semver instance. When incrementing there is an additional parameter that * can set the build metadata on the semver instance. * * ### 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 element 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` * * ### Range Grammar * * Putting all this together, here is a Backus-Naur grammar for ranges, for the * benefit of parser authors: * * ```bnf * range-set ::= range ( logical-or range ) * * logical-or ::= ( " " ) * "||" ( " " ) * * range ::= hyphen | simple ( " " simple ) * | "" * hyphen ::= partial " - " partial * simple ::= primitive | partial | tilde | caret * primitive ::= ( "<" | ">" | ">=" | "<=" | "=" ) partial * partial ::= xr ( "." xr ( "." xr qualifier ? )? )? * xr ::= "x" | "X" | "*" | nr * nr ::= "0" | ["1"-"9"] ( ["0"-"9"] ) * * tilde ::= "~" partial * caret ::= "^" partial * qualifier ::= ( "-" pre )? ( "+" build )? * pre ::= parts * build ::= parts * parts ::= part ( "." part ) * * part ::= nr | [-0-9A-Za-z]+ * ``` * * 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 * {@linkcode satisfies} function. * * This module is browser compatible. * * @example * ```ts * import { * parse, * parseRange, * greaterThan, * lessThan, * format * } from "https://deno.land/std@$STD_VERSION/semver/mod.ts"; * * const semver = parse("1.2.3"); * const range = parseRange("1.x || >=2.5.0 || 5.0.0 - 7.2.3"); * * const s0 = parse("1.2.3"); * const s1 = parse("9.8.7"); * greaterThan(s0, s1); // false * lessThan(s0, s1); // true * * format(semver) // "1.2.3" * ``` * * @module */export * from "./compare.ts";export * from "./constants.ts";export * from "./difference.ts";export * from "./format.ts";export * from "./test_range.ts";export * from "./satisfies.ts";export * from "./increment.ts";export * from "./is_semver.ts";export * from "./max_satisfying.ts";export * from "./min_satisfying.ts";export * from "./parse_range.ts";export * from "./parse.ts";export * from "./range_intersects.ts";export * from "./range_max.ts";export * from "./range_min.ts";export * from "./types.ts";export * from "./try_parse_range.ts";export * from "./is_range.ts";export * from "./can_parse.ts";export * from "./try_parse.ts";export * from "./format_range.ts";export * from "./equals.ts";export * from "./not_equals.ts";export * from "./greater_than.ts";export * from "./greater_than_range.ts";export * from "./greater_or_equal.ts";export * from "./less_than.ts";export * from "./less_than_range.ts";export * from "./less_or_equal.ts";
export const SEMVER_SPEC_VERSION = "2.0.0";
std

Version Info

Tagged at
6 months ago