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.
The inline middleware that strips the ROOT_URL_PATH_PREFIX destroys req.url. If this happens before the query parameters are parsed by use(query()) the query parameters are always missing. This causes OAuth authentication to fail when ROOT_URL_PATH_PREFIX is set.
A better fix would be to fix the path stripping logic so that it preserves the URL parameters, since other things may try to rely on them later. But this works for now.
Short-term fix for #10148.
Unfortunately, unlike most Meteor package and application code, which is
compiled after installation, Meteor compiler plugins are compiled before
they are published, so it's possible for a compiler plugin that uses the
ecmascript package to contain generated code that still uses the
module.watch API, instead of the new and improved module.link API.
A better long-term fix for this problem would be to compile compiler
plugins like any other Meteor code, using whatever version of the
ecmascript plugin the rest of the application is using.
