Ignoring environment variables in the babelrc

[Kilometers42]

It seems like Meteor is ignoring the env option in a babelrc. After you set the NODE_ENV or BABEL_ENV it appears that the Meteor build process fails to take into account the environment and run the plugins that are listed under that environment. For example, if your .babelrc looks like:

{
  "env": {
      "unittesting": {
        "plugins": ["rewire"]
    }
  }
}

and you run the command: NODE_ENV="unittesting" meteor test --driver-package practicalmeteor:mocha --port 3100

You get an error caused by missing rewire. However, if you put the rewire plugin at the top level of the .babelrc file everything works fine. All of this leads me to think that Meteor is breaking from expected babel behavior and just ignoring the env option. See: https://forums.meteor.com/t/environment-variable-in-babelrc-ignored-by-meteor-build/33166 for additional details.

[benjamn]

It's simpler than that; this package (meteor-babel) completely ignores .babelrc files by default.

If you're using meteor-babel within Meteor, then the babel-compiler Meteor package infers additional plugins from .babelrc and package.json files, but Babel itself is still prevented from looking for .babelrc configuration files.

Why reimplement this functionality? For one thing, Babel doesn't know how to find npm packages installed by Npm.depends in Meteor packages, so we really have no choice but to reimplement package resolution in terms of the inputFile.require method. So if you were thinking we might just pass babelrc: true to transformFromAst, that's unfortunately never going to work.

While I agree that supporting the NODE_ENV environment variable specifically is a good idea, I want to be very careful about allowing arbitrary reconfiguration of Babel plugins, because it has been my experience that developers will add plugins without understanding how they interact, or even understanding the order in which they run, and then complain when something breaks, which is understandable because the failures can be extremely complicated.

The current support for .babelrc files (see https://github.com/meteor/meteor/issues/6351 for the original discussion, and excellent work by @gadicc) is limited by design: you can only add plugins to the core set of plugins provided by babel-preset-meteor, and (as you discovered) only top-level presets and plugins properties are respected. Meteor does everything in its power to guarantee that babel-preset-meteor is internally consistent. If you add a plugin and it causes problems, that's not necessarily something we can fix.

With all of that background in mind, the place to think about implementing env would be the https://github.com/meteor/meteor/blob/devel/packages/babel-compiler/babel-compiler.js file, rather than this repository.

Thanks for asking, and thanks for reading this!

[Kilometers42]

@benjamn Thank you so much for the detailed answer -- I really appreciate it. My concern is that not having env respected is really confusing because it essentially breaks babel's spec -- in addition to the fact that being able to have different babel environments is very useful. I do feel that if there are weird interactions between babel plugins that should be on the developers not on the framework to hold your hand. Although you are the one who has to deal with angry github messages not me. Should I go ahead and open this as an issue in Meteor?

[gadicc]

Thanks @benjamn for the kind words still a year later :) I feel bad about this, I actually took on implementing the above "as soon as I have a chance", and that just never happened. It is telling though that no one's seem to have needed it until now :>

I also agree that supporting this is a good idea (note also that a BABEL_ENV, if it exists, is used in preference to NODE_ENV), but considering how rarely it's used it might be up to someone in the community to take this on. As usual @benjamn has provided excellent references for someone to jump in, so if you do open an issue, make sure to prominently link back to this one too.

[benjamn]

@Kilometers42 Please do open an issue over at https://github.com/meteor/meteor/issues (and link back here)!

[Floriferous]

So what is the recommended way to load different babel plugins/presets conditionally, since env in .babelrc doesn't work?

[yched]

Seconding that question.

We just switched back to the "official" Meteor build tool after using the now abandoned webpack:webpack package for a while, and losing the abitility to catch & display JS errors with readbox-react (leveraged through react-transform / react-transform-catch-errors) feels like a loss :-)

[hexsprite]

I just submitted a PR to implement .babelrc env key for babel-compiler in Meteor https://github.com/meteor/meteor/pull/8963

[skirunman]

@benjamn @hexsprite Can this issue not be closed with https://github.com/meteor/meteor/pull/8963 being merged?

[skirunman]

@benjamn @filipenevola Can this be closed?

[hexsprite]

Yes