With this commit, if a top-level package version constraint in
.meteor/packages ends with a '!' character, any other (non-!) constraints
on that package elsewhere in the application will be weakened to accept
any version of the package that is not less than the constraint,
regardless of whether the major/minor versions actually match.
This functionality is extremely useful in cases where an unmaintained
package was last published with api.versionsFrom(<some ancient version>),
thus constraining the major version of any Meteor core package it depended
on, but you really want to upgrade that core package anyway. Just put a
'!' after the core package's version constraint in your .meteor/packages
file, and you will almost certainly get your way. The fact that minimum
versions are still enforced is good/fine because the constraints you want
to override are typically ancient, so they easily match any recent version
of the package.
Your only recourse before this @x.y.z! syntax was to find a replacement
for the unmaintained package, or fork and modify it locally, or somehow
persuade the package author to publish a new version with a more
reasonable api.versionsFrom. None of these options were easy.
Many thanks to @GeoffreyBooth, long-time maintainer of the `coffeescript`
package, for originally suggesting a ! syntax similar to this one:
https://github.com/meteor/meteor-feature-requests/issues/208#issuecomment-400154209
The limitation of this syntax to .meteor/packages is deliberate, since
overriding package version constraints is a power-tool that should be used
sparingly by application developers, and never abused by package authors.
Also, limiting the scope of this syntax reduces the risk of an arms race
between overrides, a la the infamous CSS !important modifier.
- We don't want to do a bunch of parsing *per comparison* when sorting
a list of package version strings. package-version-parser's `compare`
(and server's `compare`, which it uses) both accept either a string
or a parsed record. By parsing explicitly with memoization, we avoid
a super-linear blow-up in the amount of parsing. This'll save someone
half a second, at least.
- Adjust profiling hooks and messages
- Expose `Profile` to isopackets
It used to create a directory with an underscore instead of a colon
Now, it just removes the prefix.
In cases where the name of the package has more than one colon or starts or ends
witha colon, we report an error.
In particular, ban leading `-`, trailing `.`, and `..` anywhere.
This backport commit drops the changes to constraint-solver and adds a
History.md note.
Verified manually that `meteor update asdf.` displays an error,
not a stack trace.
Include the offending name in all error messages (as we do for
invalid versions).
We now throw more specific errors, consistent between both tools and
package-version-parser (copy-and-pasted code, sadly, but we really do
have to make this check before uniload-from-checkout).
They are still used internally by the constraint solver (to implement
update --breaking) but cannot be externally specified.
Also, stop supporting "@none", whatever that was.
