A possible way to provide customizable babel configs using `.babelrc`/`env`

[jamestalmage]

Continued from:
#398 (comment)

My proposal is that we allow the following in .babelrc:

{
  "presets": ["es2015"], // base config
  "sourceMaps": "inline",
  "env": {
    "ava" : {  // if `env/ava` is present, we disable our custom config.
      "presets": ["stage-0"],
      "plugins": [] //maybe we automatically append power-assert for them?
    },
    "production" : {
     "sourceMaps": false
    }
  }
}

There are a couple questions that need to be answered in order to proceed. Specifically, can we change which env Babel uses on a per file basis? It might be as easy as setting process.env.BABEL_ENV before each call to babel.transform(..)

[billyjanitsch]

My proposal is that we allow the following in .babelrc:

This is a great start! To keep my AVA and base configs identical, do I write "ava": {}? This is a little different from how the .babelrc env field works in general:

{
  "presets": ["es2015", "stage-0"], // base config
  "env": {
    "development" : {}, // commenting this out does nothing
    "ava" : {} // commenting this out does something!
  }
}

---

Do you have plans for the general case of a custom register hook, which may transpile imports using transpilers other than Babel? Is that what --no-babel is for?

For reference, here's the hook we're passing to Mocha (which is applied to test code via --compilers, as opposed to AVA's --require which targets tests' imports). The require extensions are used to nullify webpack's aliasing & loaders.

[jamestalmage]

commenting this out does something!

Yeah - that is what I was thinking, but you raise a good point about that being an odd side-effect. If you have a different idea, this is the place to share.

Do you have plans for the general case of a custom register hook.

I think maybe --no-babel works in that scenario. My only concern is that leaves everyone else out in the cold when it comes to our caching and "transpile in the main thread" performance enhancements.

If anyone's got a list of alternative transpilers they wish they could use with AVA. I'd appreciate you sharing. Even better if you have in profiling information on those transpilers (require time via time-require and actual transpiling speed).

That said, this feels much more doable than providing performance enhancements for everyone.

[sindresorhus]

I like the idea in general, but I'll need to think about how to handle the specifics.

maybe we automatically append power-assert for them?

👍 Would be too bad if people lost out on this one and can't think of any bad side-effect of doing it.

// @ariporad @JaKXz @MoOx @kentcdodds @sotojuan @SamVerschueren @kevva

[kentcdodds]

"plugins": [] //maybe we automatically append power-assert for them?

My knee jerk reaction is to say no in favor of less magic ✨. I think that if you're going to override the default config, you should know what the default config is doing for you.

[sindresorhus]

@kentcdodds I would generally agree, but think of power-assert more like an internal plugin. It doesn't affect the functionality of the code in any way. Babel is only one of many ways to add power-assert. We use Babel since it's already parsing the source, so we can take advantage of that. It's completely different from us choosing es2015 as a preset, which does affect the code.

[kentcdodds]

That makes sense. I'm in favor 👍 Thanks for keeping me in the loop :D