Another way to fix#9888: properly handle OPTIONS requests by returning
permissive CORS headers, so that the dynamic import() server can respond
to requests from any origin.
This reverts commit 3b77bb5197.
Should fix#9888.
Sending dynamic import() requests to any origin other than location.host
causes some browsers to send a preflight CORS request ( method:OPTIONS) to
verify that the server allows the request, which was causing problems
because the dynamic import() server expects method:POST.
With the split of modern/legacy bundles, we no longer polyfill native features.
While Array.prototype.includes is available in modern browsers, flatten and flatMap are not.
This PR re-adds those polyfills to the modern bundle, for consistency with the legacy bundle.
Now that getResolver takes options, it seems inappropriate to cache only
the first resolver created, since multiple resolvers might be created with
different options.
Fortunately, caching Resolver objects is not strictly necessary (even for
performance), since Resolver.getOrCreate already caches based on the
options it receives.
The only other meaningful work PackageSourceBatch#getResolver was doing
was computing the nodeModulesPaths option, so I've cached that.
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
