Meteor 1.7 and babel issues


#1

I try to update a project to meteor 1.7 (from 1.6), but i struggle with this issue: https://github.com/vazco/uniforms/issues/433

this issue and also the recent react-native release which uses babel 7 revealed tons or problems in the community with babel (and in particular babel 7).

That makes me wonder:

  • what is the recommended babelrc file for meteor 1.7 given that meteor should now take care about what to transpile for which environment
  • is babel-preset-env still needed? shouldn’t that be the responsability of meteor?
  • what settings in babelrc can break meteor 1.7’s modern/legacy bundling?

#2

The recommendation is not to have a .babelrc at all. Meteor automatically adds the presets and plugins needed, and adding different versions of the same plugin usually causes serious issues (at best it doubles build times, at worst nothing works).

Is there a particular plugin that you need that Meteor doesn’t give you?


#3

typically I have the “styled-components” babel plugin, which automatically sets display names for better debugging, the “lodash” plugin, that rewrites lodash imports, so that only needed imports are cherry-picked, the “flow” preset for flow-type… stuff like that.

I don’t agree that its best to not have a babelrc file. It’s a good thing that we can add plugins and presets, but on the other hand, it’s hard to debug, once you got some problem.

I think it would be good to have a section on guide.meteor.com about babel and its pitfalls


#4

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-es2015 or 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 package.json file.
  • 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:


#5

@coagmano is exactly right, the presence of preset-env in .babelrc eliminates many of the benefits of differential compilation that Meteor 1.7 claims to provide. That’s why the plan for Meteor 1.7.1 is to ignore preset-env if it appears in .babelrc, since its functionality is already covered by the presets we use for modern/legacy/Node compilation. Please keep in mind that plugins in .babelrc apply equally to both modern and legacy code!


#6

thx @benjamn and @coagmano, that should make it clear!