As discovered in #8947, creating an app with
meteor create --release 1.4.4.1 new-app
does not actually constrain core packages to have the same minor versions
they had when Meteor 1.4.4.1 was published. Rather (as of Meteor 1.4.3),
the Meteor release only constrains core packages to have versions at least
as recent as the versions they had when the release was published, and to
have the same major version. Any later minor version is fair game.
What we need is a new kind of package version constraint, more like
semver's ~ range operator:
https://www.npmjs.com/package/semver#tilde-ranges-123-12-1
This commit implements that functionality, though it stops short of
supporting all possible semver range syntax.
Backports: b7645a4d1f
* Downgrade uglify-es from 3.3.10 to 3.3.9 (latest published).
PR #9652 by @klaussner upgraded `uglify-es` from 3.2.2 to 3.3.10 to fix
issue #9647, but 3.3.9 is the latest version published to npm, and 3.3.10
seems to suffer from this bug: https://github.com/mishoo/UglifyJS2/issues/2896
For that reason, I think it might be best to downgrade `uglify-es` to
3.3.9, at least until 3.3.11 is published.
Since this bug causes `uglify-es` to throw during minification, the
`meteorJsMinify` function falls back to Babel's minifier, which is known
to use massive amounts of memory, and may be contributing to OOM problems
such as #9568. In other words, there's a chance that this downgrade will
help with #9568.
* Also bump standard-minifier-js package version.
If a package in node_modules needs to be compiled for older browsers,
simply symlink the package directory into your application somewhere, and
then import the package as you normally would.
Because of the symlink, code within the package will be compiled as if it
was part of your application, and any imports that refer to modules in the
package will automatically use the compiled code rather than the raw code
from node_modules.
Note that you can also symlink individual files to make them be compiled
like application modules, rather than linking an entire package directory.
Creating symlinks could be considered a form of configuration, but
otherwise this is a zero-configuration solution to selectively compiling
packages within node_modules, which has been something of a holy grail in
the JavaScript community lately.
https://github.com/meteor/meteor-feature-requests/issues/6
The bulk of this commit implements `builder.copyNodeModulesDirectory` to
allow more than one `node_modules` directory to be copied to the same
destination with as much safe symlinking as possible.
However, the crux of the fix for #9738 is the removal of the call to
`builder.generateFilename`, which deserves additional explanation.
If multiple directories are copied to the same output path by the builder,
in some cases it makes sense to ensure distinct directory names by adding
numeric suffixes to some of the directories.
In general, `builder.generateFilename` can get away with this renaming
only if the exact names of the directories are an implementation detail.
However, the code changed by this commit was altering the names of
`node_modules` directories whenever a package had both an `Npm.depends`
and a local `node_modules` directory.
Not only is it totally invalid to change the name of a `node_modules`
directory, but there is also no harm in copying the contents of multiple
`node_modules` directories into one final directory called `node_modules`.
Should fix#9738.
