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.
* 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.
Supporting "module" in package.json for server code is not advisable
because Node.js will be adopting the "type":"module" convention instead,
and in the meantime we need to maintain consistency with Node's module
resolution rules, which only currently pay attention to "main":
https://medium.com/@nodejs/announcing-a-new-experimental-modules-1be8d2d6c2ff
This should have been done when PR #10299 was first merged. Thankfully,
@macrozone discovered the problem while diagnosing issue #10530.
Should fix#10530.
The promise package needs a weak dependency on this package (on the
server) because meteor-promise saves a reference to Fiber.yield, so we
need to have wrapped Fiber.yield with noContext before that happens.
* Update cordova-plugin-meteor-webapp to version 1.7.0.
Fixes#10516.
* Bump meteor-tool and webapp to a temporary 1.8.1-issue-10516.0 version.
I attempted to publish webapp@1.7.4-rc.0 with @rj-david's changes from
https://github.com/meteor/cordova-plugin-meteor-webapp/pull/78 to verify
that they fix#10516, but prerelease versions like 1.7.4-rc.0 are not
compatible with non-prerelease core package constraints like ~1.7.3 (which
desugars to >=1.7.3 <1.8.0), as explained by this comment in the semver
source code: 5fb517b290/semver.js (L1246-L1250)
While this behavior was somewhat surprising to me, I haven't come up with
a way to fix it without accidentally allowing any prerelease version of
core Meteor packages to be installed in applications using an official
(non-prerelease) version of Meteor.
Instead, we can just cut a temporary prerelease version of Meteor itself.
If that fixes the problem, then we can publish webapp@1.7.4 safely,
without actually publishing a Meteor 1.8.1.1 release just for this.
* Update webapp to version 1.7.4 (without -issue-10516.0 suffix).
Now that we've moved into the release candidate phase, there will be no
more new features added to Meteor 1.8.1, and all remaining effort will be
focused on fixing bugs.
Please test the release candidate if you have time, by running the
following command in any application directory:
meteor update --release 1.8.1-rc.0
