Meteor 1.7 and babel issues

help
1

I try to update a project to meteor 1.7 (from 1.6), but i struggle with this issue: meteor 1.7.0.1 - TypeError: Class constructor _class cannot be invoked without 'new' · Issue #433 · vazco/uniforms · GitHub

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?

1 Like
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:

4 Likes
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!

7

@coagmano @benjamn Hello! It is difficult to find any documentation on how Meteor handles babelrc, and I haven’t looked at that part of the source yet. The ecmascript page in the docs doesn’t mention babelrc. Is that the best place to add documentation for it?

If I put a babelrc file at the root of my Meteor app with only one plugin, does this delete all the Meteor settings and I need to manually specify those again?

Based on @benjamn’s previous comment, it seems that the custom babel config gets merged with the existing Meteor babel config.

8

Yeah I think that would be the right place.

No, it will be merged with Meteor’s config.
The issue with preset-env is that it contains a large number of configs and legacy/modern bundling

9

@coagmano If babelrc is merged with Meteor’s, and I am getting the error described in Error ''Missing class properties transform.'' when use Mobx in meteor, does that indicate that Meteor doesn’t support class fields yet?

I’m basically having that same issue. This is what I had to do in .babelrc to get things working:

{
  "presets": ["solid"],
  "plugins": [
    [
      "@babel/plugin-proposal-decorators",
      {
        "legacy": true
      }
    ],
    "@babel/plugin-proposal-class-properties"
  ]
}

My code was using a decorator on a class field like this:

class Foo {
  @sparkly name = 'foo'
}

That’s ultimately what led me to this thread, is that I was trying to determine what Meteor does with babelrc, and I had assumed babelrc would be merged with Meteor’s and that Meteor would also handle class fields nowadays.

10

I wonder if there’s an interaction with the solid preset?

I use class properties quite often without a babelrc, so :man_shrugging:

11

Yeah, that’s why I was confused. Hmmm… :thinking: