Short-term fix for meteor#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.

Should fix meteor#10088.

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.

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:
meteor/meteor-feature-requests#208 (comment)

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.

Following up on this promise:
meteor#9942 (comment)

…ackage depends on to their latest versions as of Meteor 1.7.0.4; this enables modern browsers JavaScript output

…dd missing import statements

Should help mitigate meteor#10147.

https://nodejs.org/en/blog/vulnerability/august-2018-security-releases/

…undle.

Should help mitigate meteor#10147.

… bundle.

Release 1.7.0.5

…n-browsers

CoffeeScript 2.3.1, with support for setMinimumBrowserVersions.

After publishing coffeescript@2.3.1_1, I noticed that the version of
babel-runtime (1.2.5) that is bundled into the compile-coffeescript plugin
was complaining about the presence of @babel/runtime@7.0.0-rc.1 in the
node_modules directory of Meteor 1.7.1-rc.3 apps, thanks to code added
recently to work around breaking changes in @babel/runtime@7.0.0-beta.56:
4d5fff9

The easiest way to fix this problem in the short term is to give the
compile-coffeescript plugin its own reliable copy of the @babel/runtime
npm package, rather than delegating to the version installed in the app.

The ideal long-term way to fix this problem would be to stop precompiling
Meteor compiler plugins before publishing them, and instead treat them
like any other Meteor package, which are compiled after installation.

Another issue that could have been prevented if compiler plugins were
compiled upon installation, like other packages: meteor#10148

cc @hwillson @abernix @GeoffreyBooth

This should make the @babel/runtime dependency that I added to the
compile-coffeescript plugin in a52a2c2
actually work as intended.

Specifically, the babel-runtime package that's bundled into the
compile-coffeescript plugin will now be able to import @babel/runtime and
receive the plugin's private version of @babel/runtime, rather than the
one in dev_bundle/lib/node_modules or the application's node_modules.

cc @hwillson @abernix

We should wait to publish this change until after Meteor 1.7.1 has been
released (cc @GeoffreyBooth).

…10184)

Follows-up: 72794df.

cc @benjamn @hwillson

Meteor 1.6.x through 1.7.0.x use the `babel-runtime@1.2.x` packages, and
this change is only intended to affect those versions.

This will no longer be necessary in Meteor 1.7.1, since we account for
the changes to `@babel/runtime` through changes to the `meteor/babel`
package, but this ensures that anyone who updates to `@babel/runtime@7` (the
final, latest release), or anything newer, isn't surprised by their broken
application.

Fixes several cases causing cordova plugins reinstall on every build:
- proper handling of scoped npm cordova plugins
- proper detection of plugin removal (previously a cordova plugin containing a dependency would make the algorithm think a package was removed from cordova-plugins)
- proper handling of plugins which have plugin.xml id different than the npm package name
Additionally rechecks the build integrity verifying if packages were really installed and perform a retry if needed.
Allows to override a meteor package cordova dependency with scoped package i.e. @scope/cordova-dummy-plugin will now override a cordova-dummy-plugin dependency.

Still waiting on a fix for this issue in 4.0.3:
https://jira.mongodb.org/browse/SERVER-36474

https://stackoverflow.com/questions/49800534/powershell-could-not-create-ssl-tsl-secure

Fixes meteor#10189.

In theory, these delayed rebuilds should not even be noticed, so it
doesn't make sense to draw attention to them.

Cordova plugin handling algorithm consistency improvements

Follow-up to af51b81, which fixed meteor#8005 by copying symlinks to external
directories as directories rather than trying to preserve the symlinks.

Issue meteor#10177 revealed a flaw in this strategy: the filter function that we
use to strip development npm packages always rejects external paths, even
if the original symlink was found in a valid production npm package, and
thus its contents should be included in the production bundle.

In the process of fixing this problem, I realized that the only important
part of af51b81 was this code:

  // Update fileStatus to match the actual file rather than the
  // symbolic link, thus forcing the file to be copied below.
  fileStatus = optimisticLStatOrNull(externalPath);

and the code for manipulating thisAbsFrom and _currentRealRootDirectory
could be removed.

…e 1.6.1 (meteor#10204)

My attempt at fixing meteor#10195.

@klaussner Feel free to submit your PR if it's ready, or just review this
one if you prefer. It's important to get this right, so it's not a
terrible idea for both of us to attempt it independently.

…on-handling

Implement MongoDB 4.0 transaction handling in oplog_tailing.js

Previously: a52a2c2

This change dramatically reduces the number of attempted files.stat calls
during module resolution, especially for apps that use a large number of
compiler plugins, and thus have many different file extensions to try.

meteor#10214)

meteor#10209)

Closes meteor#10090.

Follow-up to 8d4f07a.

Should fix meteor#10165.

)

* Rename file that breaks development on Windows

* Fix: failing test bundle - verify sanitized asset names

This minor update was evidently too risky to slip into a release candidate
of Meteor 1.7.1: meteor#10216

You can still use Node 8.12.0 to run your app in production, and thus get
the benefits of meteor#10090, even if it's
not the version used in development.