As illustrated by #9554, if a custom .babelrc plugin such as
@babel/plugin-proposal-optional-chaining imports a missing dependency such
as @babel/core, that failure causes inputFile.require to throw an
exception that looks a lot like @babel/plugin-proposal-optional-chaining
itself is missing, which can be confusing.
This change does not fix the underlying problem (the @babel/core package
still needs to be installed), but it does expose the exception so that the
developer can do something about it, rather than merely leaving the ?.
syntax uncompiled.
Here's the offending line of code:
47ce7e71c9/packages/babel-plugin-proposal-optional-chaining/src/index.js (L2)
Unfortunately, depending directly on @babel/core seems to be the policy
for Babel plugins, per this PR: https://github.com/babel/babel/pull/6778
This functionality was added in reify@0.13.3:
10c90cd0a2
The changes to modules-test-plugin/plugin.js cause files like array.arson
to mirror array.arson.js, which exercises module.makeNsSetter(true) and
relies on default exports.
While Babel 7 seems to work perfectly well, and the process of upgrading
has been useful, the upgrade is going to require Meteor developers to
update the babel-runtime npm package and their .babelrc plugins, a chore
with which Meteor can't help very much.
On top of that, Babel 7 is still in early beta. I don't want to ship
Meteor 1.6 with a critical component that could change in unexpected ways,
and I don't want to wait for Babel 7 to be finalized to ship Meteor 1.6.
Note that the Meteor command-line tool is still implemented using Babel 7,
which has historically been a great way to gain confidence in
Babel-related changes before pushing them out to all Meteor developers.
@GeoffreyBooth This should take some pressure off the CoffeeScript upgrade
for now. Let's aim for Meteor 1.6.1 for Babel 7 and CoffeeScript 2.0.
The modules test app appears to be running with process.env.NODE_ENV equal
to "production" on Circle CI: https://circleci.com/gh/meteor/meteor/5030.
Enabling this transform in production as well as development is fine
because we primarily want to test that plugins from the "env" section of
.babelrc are respected, regardless of the value of process.env.NODE_ENV.
Using different plugins in production might be worth testing, too, but
that's less critical.
Follow-up to #8963.
This polyfill is unnecessary in Node, and added a whopping 22KB to the
minified client bundle. If you really need the Buffer API on the client,
you can get it from require("buffer").Buffer.
