The @babel/plugin-transform-runtime@7.0.0-beta.56 plugin used by
meteor-babel@7.0.0-beta.56 now generates code that imports helpers from
@babel/runtime@7.0.0-beta.56, which no longer relies on core-js:
https://github.com/babel/babel/pull/8266https://github.com/babel/babel/releases/tag/v7.0.0-beta.56
This is not much of a change for modern browsers, since we were already
using @babel/runtime/helpers/builtin to avoid relying on core-js. However,
for the legacy bundle, it's now more important than ever that we import
appropriate core-js polyfills in ecmascript-runtime-client, since they are
not going to be imported as a side-effect of using @babel/runtime.
That means there's no longer as much benefit to sharing the application's
copy of core-js with ecmascript-runtime-client, so it seems simpler just
to give ecmascript-runtime-client its own private copy of core-js, so that
it can import appropriate polyfills without forcing the developer to
install core-js explicitly in the application.
Probably the most notable change in this update is that the Reify compiler
now generates
module.link("./child", { ...setters... });
instead of
module.watch(require("./child"), { ...setters... });
for import and export-from declarations.
This hack dates all the way back to 2013: a2c4a78743
Though it is convenient to reload the browser when server files change
while running test-packages, that's not the behavior of most Meteor apps
that use the autoupdate package, and this hack introduced a signficant
difference in behavior between the test-in-browser and test-in-console
driver packages, which finally surfaced due to the interaction between
@toinevk's headless testing PR #9814 and my refactoring of the autoupdate
package (fe9e4035f9). Tests should behave
the same regardless of which driver package is used.
It turns out there's a better way to make the browser reload each time the
server restarts: simply modify Meteor.settings.public, since that object
is included in the client hashes computed by the webapp package.
It seems obvious in hindsight, but any logic relating to the
AUTOUPDATE_VERSION override should reside within the autoupdate package,
and the true client hashes should be available to any other package that
needs them, without AUTOUPDATE_VERSION getting in the way.
