mirror of
https://github.com/meteor/meteor.git
synced 2026-05-02 03:01:46 -04:00
e885e78348
This is a breaking change to package-version-parser.
A PackageConstraint used to look like this:
```
{ name: String,
constraintString: String,
constraints: [{version: String|null,
type: String}]}
```
Now it looks like this:
```
{ name: String,
constraintString: String,
vConstraint: {
raw: String,
alternatives: [{versionString: String|null,
type: String}]}}
```
Where (vConstraint instanceof VersionConstraint) and
(vConstraint.raw === constraintString).
This achieves several desirable changes at once.
* `constraint.constraints` for the disjuncts in “1.0.0||2.0.0”
was confusing. `alternatives` is better.
* Having a class for VersionConstraint will come in handy because
we can add methods to it, and we can use it in the constraint
solver to represent the problem statement.
* The names “vConstraint” and “versionString” are a little verbose,
but there really shouldn’t be a lot of code that dives into this
structure, and I really wanted to avoid anyone ever writing:
`constraint.constraint.alternatives[0].version`, and then wondering
what sort of object that was (not a parsed PackageVersion! we could
parse eagerly but that might be slow).
18 lines
422 B
JavaScript
18 lines
422 B
JavaScript
Package.describe({
|
|
summary: "Parses Meteor Smart Package version strings",
|
|
version: "3.0.0"
|
|
});
|
|
|
|
Package.onUse(function (api) {
|
|
api.export('PackageVersion');
|
|
api.use('underscore');
|
|
api.addFiles(['semver410.js',
|
|
'package-version-parser.js']);
|
|
});
|
|
|
|
Package.onTest(function (api) {
|
|
api.use('package-version-parser');
|
|
api.use(['tinytest']);
|
|
api.addFiles('package-version-parser-tests.js');
|
|
});
|