Probably the most notable change in this update is that the Reify compiler
now generates
module.link("./child", { ...setters... });
instead of
module.watch(require("./child"), { ...setters... });
for import and export-from declarations.
This package is already importable because it's a dependency of request,
npm, and http-signature, but it's a good idea to depend on it explicitly
just in case those packages stop depending on it in the future.
This version no longer includes the cache directory in the computation of
the cache key, which allows repeated test runs to reuse compilation
results from previous runs.
Instead, the cache directory is provided as part of the third argument to
Babel.compile, which means we can set the cache directory per instance of
BabelCompiler in BabelCompiler#setCacheDir.
This became a problem because coffeescript was calling
the setCacheDir method of its own instance of BabelCompiler, which was
racing with the setCacheDir call for the ecmascript package:
f601ec9693/packages/non-core/coffeescript/compile-coffeescript.js (L27)
I tried removing babel-runtime from the dev bundle in a recent commit
(since @babel/runtime is what Babel 7 uses), but some tests failed.
Unfortunately Meteor packages like stylus that (1) register compiler
plugins and (2) were last published before Meteor 1.6.1 still need the
older version of the babel-runtime npm package. It's an extra 2MB of dev
bundle size (82MB vs. 80MB), so it's not the end of the world, but I would
like to figure out how to remove it permanently at some point.
cc @abernix @hwillson in case you have any quick thoughts
146c11425b
The recent 7.0.0-beta.39 versions of some Babel dependencies snuck into
the last dev_bundle/lib/node_modules build, due to using ^7.0.0-beta.38
version constraints in babel-preset-meteor/package.json, even though
meteor-babel exactly pins the version of babel-preset-meteor.
After I rebuild the dev bundle, this change should fix the current test
failures on the devel branch.
Since these packages aren't published to the npm registry, they can be made private to avoid unnecessary warnings about missing description, repository, and license fields when installing server dependencies and generating dev bundles.
