Update our Babel usage to only apply stage-4 transforms

[novemberborn]

Our current Babel usage is a bit confusing, and applies too many transforms (stage-2 even!): https://github.com/avajs/ava/blob/a380fe4f5ffa1d334a2a3786215d3c1ff10a9898/lib/babel-config.js#L43:L48

Per RFC001 we will only apply stage-4 transforms. We must only apply transforms for features that are not natively supported on Node.js 4 and 6 respectively. We must not polyfill the environment.

I'm thinking we may have to roll our own preset to do this properly, given that https://www.npmjs.com/package/babel-preset-es2015-node4 is deprecated in favor of https://github.com/babel/babel-preset-env, which pulls in unnecessary dependencies. https://www.npmjs.com/package/babel-preset-node6, confusingly, talks about ES2015 yet we need ES2017.

[sindresorhus]

Yeah. We need a custom preset.

[mightyiam]

I'm looking forward to this. Debugging should be more clear without unnecessary polyfills.

Did we think about automatically detecting target?

And what's wrong with stage 2? No one has to actually use any proposed future...

[novemberborn]

And what's wrong with stage 2? No one has to actually use any proposed future...

But they might, accidentally.

When AVA started the language features that are now in ES2017 and earlier where not even shipping in Node.js. That's completely changed now, Node.js 8 should have full ES2017 support I think. AVA can still focus on making these features available to older runtimes but it doesn't need to advocate for features in earlier stages of development. This also aligns us with ESLint, which only supports stage-4 features.

[mightyiam]

Alright. What about target detection? We are on target runtime. So why don't we detect and set the target accordingly?

[novemberborn]

What about target detection? We are on target runtime. So why don't we detect and set the target accordingly?

That's the plan.