This includes https://github.com/laverdet/node-fibers/pull/429, fixing the
CPU spikes reported and discussed here: https://github.com/meteor/meteor/pull/10527#issuecomment-567982128
Using an official fibers release rather than a GitHub URL is preferable
because it doesn't require building fibers from source when deploying a
Meteor app to production, and also doesn't rely on GitHub being
operational, though of course it does rely on other networked services
like npm.
Apparently calling v8::Isolate::AdjustAmountOfExternalAllocatedMemory
frequently results in lots of wasted CPU cycles on garbage collection, per
discussion here: meteor/meteor#10527 (comment)
This fix was inspired by marudor/libxmljs2#22, which seems to have
addressed nodejs/node#30995.
Another project that benefitted from adjusting external allocated memory
less often: mapnik/node-mapnik#136
source-map 0.7.0+ has a much faster Rust WASM implementation.
Because this needs to be loaded, the constructor is now asynchronous.
The consumer should also be destroyed after it's no longer needed.
Should help with #10795.
Also updating the meteor-babel and @babel/runtime versions in the dev
bundle, though there is no need to rebuild the dev bundle immediately.
This reverts commit 5124cb495c.
Perhaps unsurprisingly, JSON5 is much slower than JSON, so much so that
"other optimisticReadJsonOrNull" has become the single most expensive leaf
when building one of our internal applications. We will have to find
another solution.
Because json5 is more tolerant of non-standards-compliant input, it has no
trouble with \t tab characters outside of string literals, so this change
should fix issue #10688.
Note that json5 is already installed in dev_bundle/lib/node_modules/json5,
because it is a dependency of @babel/core, so we don't need to rebuild the
dev bundle immediately, though it would be a good idea to do so before the
next beta/RC release.
Because json5 is more tolerant of non-standards-compliant input, it has no
trouble with \t tab characters outside of string literals, so this change
should fix issue #10688.
We don't need to build a whole new dev bundle just for this upgrade, since
we've already worked around the bug that it fixes, but it will get picked
up the next time we build the dev bundle for Meteor 1.8.2.
This ensures we wrap modules with a function to rename the `module`
identifier to something more reliable when the ImportScanner compiles
unanticipated modules imported from node_modules.
