Should fix#10595.
Code from the application `node_modules` directory becomes part of the
`modules` package, so that it can be imported by any other package that
uses the module system, regardless of package load order.
Now that we compile code from `node_modules` using `babel-compiler` and
`meteor-babel` (#10585), `node_modules` code requires the same runtime
environment as any other Meteor JS code. For the most part, this need is
satisfied by the `@babel/runtime/helpers/...` modules, which are also
defined in the `modules` package because they come from `node_modules`.
However, in the legacy bundle, `meteorBabelHelpers.sanitizeForInObject` is
used to fix buggy for-in iteration in older Internet Explorers.
Thankfully, this extra helper code does not need to be included in the
modern or server bundles, but only in legacy code.
Case in point: @babel/runtime/helpers/esm/typeof.js uses ECMAScript module
syntax (import, export), but must not be compiled with transforms like
@babel/plugin-transform-typeof-symbol, since it's part of the runtime
library depended upon by that transform.
This logic is an extreme implementation detail for sure, but at least
babel-compiler is the only code that needs to know about this complexity.
Now that we have the ability to invoke Babel via compiler plugins for
individual modules encountered by the ImportScanner, it's possible the
ImportScanner will try to compile @babel/runtime/helpers/* modules.
These modules are not safe to recompile because they use native syntax
(such as typeof) in ways that do not need additional transformation or
simulation, and would be broken by applying the usual Babel transforms.
It may bother you that this list of packages is hard-coded, or that it
might grow over time. To ease those concerns, I would say:
1. We can release new versions of the babel-compiler and ecmascript
packages whenever we need to.
2. These particular npm packages belong in this list because Babel
itself assumes they have already been compiled, so there shouldn't be
(m)any other packages that fit that narrow criterion.
In other words, this is just a list of packages that must be left
untouched in order to bootstrap the Babel compiler system, and the
babel-compiler package is where the details of that system primarily
reside, so that's where we should put this list, until/unless we find a
better solution.
Instead of merely supporting ECMAScript module syntax via Reify, we should
really be compiling unanticipated modules (typically within node_modules)
using the same logic that the rest of the application uses.
Note: this processing applies only to .js files for now, since that's what
the ImportScanner works with.
Should help with #10563.
* Update ecmascript-runtime-{client,server} to core-js@3.1.4.
Also added a polyfill for Symbol.asyncIterator to server, modern, and
legacy, which should fix#9897.
* Add a test of for-await-of async iteration.
This should verify that #9897 is fixed.
We ended up with two different versions of the reify package (0.19.0 and
0.19.1) in the last build of the dev bundle, which seems to have caused
the test failures.
