When we copy node_modules directories during rebuilds, we try to create
symlinks instead of doing a full recursive copy. Very often, however, the
symlinks already exist, and they point to the right location already, so
we can avoid recreating them for even better performance.
Another optimization identified by using the qualia:profile package
created by @veered: https://atmospherejs.com/qualia/profile
I've noticed that sometimes it takes a while for cache files to be fully
written and renamed, so I think we can speed things up while still
preserving the asynchronicity by doing the rename synchronously in the
async fs.writeFile callback.
It's important not to involve cacheDirectory in the computation of cache
keys, since that introduces too much diversity, especially when running
tests, since tests use temporary directories with randomized names.
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.
This reverts commit 7a2e492b6c.
The custom build had a Node version of
8.11.2-nightly1525879461436bd3e42eb10ddd15a9fc1ed225d49c87ad7214 instead
of 8.11.2, which is not something that I want Galaxy (or any other hosting
service) to have to understand.
That is, instead of using the official 8.11.2-rc.1 release candidate.
Note that we're still using 8.11.1 on Windows, since the official RC has a
bad process.release.headersUrl.
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)
This only affects newly created applications for now, but developers can
update to the latest meteor-node-stubs by running
meteor npm install meteor-node-stubs@latest
https://github.com/meteor/node-stubs/issues/15
IE10 does not support setting the __proto__ property of objects as an
alternative to Object.setPrototypeOf. Because Babel generates code that
uses the @babel/runtime/helpers/inheritsLoose helper, and that helper
relies on setting __proto__, subclassing fails in Babel-generated code in
IE10 (and earlier), which causes a white screen of death in newly created
Meteor apps.
This commit checks whether setting __proto__ works, and (if not) overrides
the inheritsLoose helper with an implementation that does not rely on
setting __proto__. This logic applies only in legacy browsers, thanks to
api.addFiles("legacy.js", "legacy").
Although this shim isn't perfect (for example, there is no way to set up
true inheritance of static properties), it will allow inheritance to work
in browsers that would otherwise be completely broken.
Since IE10 represents only 0.1% of the world market, we should not
overinvest in keeping it working, but this seemed like a good opportunity
to take advantage of legacy bundling, without adding any new code to the
modern bundle.
All Meteor packages implicitly depend on the meteor package, and the
meteor-base package implies the meteor package for most Meteor apps, but
the new minimal skeleton does not use meteor-base, so minimal Meteor apps
were not directly depending on the meteor package.
The only reason this mattered was that the meteor package registers a
default compiler plugin for CSS files, and compiler plugins only apply if
an app or package directly depends on them (or depends on a package that
implies them, such as meteor-base).
In other words, this change reenables support for raw CSS files for
minimal apps.
