I just looked up where I got the idea that not having one was recommended, and I’m pretty sure I’m wrong.
There was advice in the Meteor 1.6.1 announcement blog to be careful around any babel configs and plugins since the migration to babel 7 was pretty major, but no official recommendation not to use it:
From Meteor blog 1.6.1
link : https://blog.meteor.com/announcing-meteor-1-6-1-50aad71da4e6
If your team has added custom Babel plugins to a
.babelrc file, now is a good time to make sure they all work with Babel 7. In particular:
- Please revisit the use of any presets like
babel-preset-env, as Meteor provides similar functionality via
babel-preset-meteor. Redundant presets waste compilation time (at best) or introduce bugs (at worst) because not all plugins can safely run twice. Here’s a recent example of a Babel bug stemming from redundant Babel plugins. Instead, you should rely as much as possible on the defaults provided by Meteor, and carefully add individual plugins as needed, rather than blindly adding plugins or presets that you may not need. That might have worked in the past, but Babel 7 could expose hidden problems.
- If you’re using an official Babel plugin such as
babel-plugin-transform-decorators, there’s a good chance it has been renamed to something like
@babel/plugin-proposal-decorators. This blog post details the rationale behind this renaming, and may help you guess what the package is now called. Otherwise, you can search for the old package name here, and then look for the new package name in the current
- Please refer to this blog post for general guidelines for upgrading to Babel 7, especially if you encounter problems after updating to Meteor 1.6.1.
We can provide assistance via GitHub issues, but please be aware that Meteor cannot guarantee the functionality of arbitrary
.babelrc configurations. When you depart from the core Babel functionality provided by Meteor, you embrace the additional maintenance burden, for better or worse. We’re depending on you to appreciate the difference between a problem that Meteor can solve and a problem inherent in the complexity of your custom configuration.
Though I did see in the docs that there’s a list of included babel presets here:
So you can check to make sure you’re not doubling up
So I guess in short:
babel-preset-env is not needed (and probably harmful)
- Add the specific plugins that you want / need
- No idea how it affects split bundling
EDIT: Just went for a dive through
babel-compiler and it looks like extras in
.babelrc get applied to both bundles.
So if you had
babel-preset-env in there, it would undo the benefit of split bundling
The list of transforms for legacy is here:
and modern here: