Make "babel": "inherit" the default

[kentcdodds]

Description

I've shared AVA with a lot of people and the number one thing that trips them up is that the Babel configuration that transpiles their own code is different from the config that transpiles their test code. For most of them, if they're writing their source in ES6, they expect their tests to be able to transpile with the same config.

So my request is that we default to "babel": "inherit" where we look for a .babelrc and if it exists, use that for config.

Thoughts 💭

[novemberborn]

It'd be hard to guarantee the behavior AVA promises (async/await for instance) if it might be affected by users own code.

Maybe ava --init could detect a local Babel install and suggest this setting. And automatically set up babel-register too!

[jamestalmage]

Are people usually adding stage-3 to their Babel configs? Because AVA really needs that to provide all the async/await goodness.

Perhaps we should automatically add stage-3 to the detected .babelrc? If the user goes so far as to actually specify the inherit option then we assume they know what they are doing and only add power-assert?

There is a tension here between doing too much magic and asking the user to write extraneous config. Always a hard decision.

[kentcdodds]

It'd be hard to guarantee the behavior AVA promises (async/await for instance) if it might be affected by users own code.

I think that people will understand that if their babel config doesn't support something, they can't use it. They're coding their ES6 in their source with this config all day every day. I think it'll be natural to continue using what they're used to using.

But if you'd rather, we could validate that the config has the properties necessary.

I like the idea of an ava --init but not everyone will set up AVA that way and I think it'll still be confusing for people.

Perhaps we should automatically add stage-3 to the detected .babelrc

Seems like to much ✨ magic ✨ to me.

Always a hard decision.

Agreed :-) But like I said, I hear over and over again that people have trouble understanding that the tests and source are compiled differently. It's just confusing to people. So I think we could do something about it. :-)

[levithomason]

-1 to magic, +1 to defaults or some kind of init. I ran into a hangup here as well. The docs seem to indicate if you "babel": "inherit" in your ava config, then your tests are transpiled same as your source. However, I also had to "require": "babel-register" or nothing was transpiled.

So, I'd suggest the default be at least the minimal to start testing using your current source babel config:

"ava": {
  "babel": "inherit",
  "require": [
    "babel-register"
  ]
},

I have not done a thorough review of this so I may be over looking more.

[jamestalmage]

However, I also had to "require": "babel-register" or nothing was transpiled

Your tests should have been, it's a bug if they weren't. Compiling sources would need require: 'babel-register'. 👍 for documenting that better.

[levithomason]

Oh, "sources". I think I understand the point of this whole issue now, thanks.

[novemberborn]

I'm coming at this from the other direction: I love to fiddle with Babel config for my source code but would rather not fiddle with AVA's config.

@kentcdodds what presets/plugins do you see people using that are not in stage-2 or es2015? Is this perhaps a JSX issue? We can definitely support that better out of the box.

[kentcdodds]

I think we've only begun to see people start to leverage babel plugins. I think that as time goes on, people will get used to using more and more plugins.

Regardless though, I think that it's confusing for people that the config used to transpile tests is different from the config used to transpile tests ¯_(ツ)_/¯

[novemberborn]

The features we describe in https://github.com/sindresorhus/ava#es2015-support should work out of the box though. Not opposed to merging the configs though. IIRC that could be achieved by making {babelrc: true} the default.

[jamestalmage]

The features we describe in https://github.com/sindresorhus/ava#es2015-support

Exactly, I would want async-await to work for users regardless of whether they specified that in their .babelrc.

[kentcdodds]

I would want async-await to work for users regardless of whether they specified that in their .babelrc

And from my perspective, I don't think that people would use async await if they couldn't do so in their source because I generally like to write my tests and source in a similar fashion.

I like the idea of merging configs by default. That would definitely solve my concerns and allow people to use everything that AVA supports by default. 👍

[jamestalmage]

And from my perspective, I don't think that people would use async await if they couldn't do so in their source because I generally like to write my tests and source in a similar fashion.

I'm sure that's true for a lot of people. Most of the core AVA team is fully bought in to small-module design, and for small modules it is often easier to write them to work without transpilation. This isn't a new idea - I've seen plenty of modules that write sources in pure JS and tests in CoffeeScript.

One justification for the CoffeeScript approach is that it lowers the barrier for contribution for users who don't use CoffeeScript. Also, stack-traces pasted in GH comments are useless if you have transpiled and the user hasn't installed sourcemap-support

[novemberborn]

And from my perspective, I don't think that people would use async await if they couldn't do so in their source because I generally like to write my tests and source in a similar fashion.

I have a slight distrust of Babel's transform output for async/await, plus it's not necessarily a settled feature. Personally I'm happy to take that risk in tests but not necessarily in production code.

---

@sindresorhus @vdemedes @jamestalmage thoughts on merging config by default?

[novemberborn]

@avajs/core bump :)

[sindresorhus]

plus it's not necessarily a settled feature

It is now 😎

thoughts on merging config by default?

I would be ok with that, as long as we have very clear docs about the behavior, so there's very little chance of confusion.

[novemberborn]

Our Babel plans are here: https://github.com/avajs/ava/blob/master/docs/specs/001%20-%20Improving%20language%20support.md