Upgrade to Babel 6

[jamestalmage]

#221 Was so outdated it was easier just to start fresh than rebase.

There is one remaining issue from the comments on that PR. This PR still does not intelligently drop babel-plugin-transform-async-to-generator. That plugin is now buried in the stage-3 preset, and I'm not sure if there is a way to still use that preset, but tell it to exclude that particular plugin. Recreating that preset would be fairly trivial (it aggregates only two plugins). I am not sure that is a good plan though. By definition, the stage-3 preset is subject to change over time, and it seems to me that we want to automatically stay up to date. We already track this with #148. Is there something special about async-to-generator that we feel we must handle it specially now before we "do it right" with #148?

[twada]

babel-preset-stage-2 includes babel-preset-stage-3 so you only need stage-2

[jamestalmage]

Good point.
When I started, I thought I only needed stage-3. I was unaware Object Rest/Spread arguments were stage-2.

[sindresorhus]

Is there something special about async-to-generator that we feel we must handle it specially now before we "do it right"

I don't know how that plugin works now, but we need to polyfill generator support on Node.js 0.10. I don't really have a strong opinion of how that's solved though.

[jamestalmage]

I read it wrong. We were dynamically blacklisting regenerator function, not async-to-generator. The decision to do that dynamically was made back in #61. Now that we reformat stack traces with source-map-support I don't think it is that big of deal.

[sindresorhus]

@jamestalmage We only want to include regenerator on Node.js 0.10 though, as it's a lot slower than native generators.

[jamestalmage]

OK,
The Babel docs no longer mention the ability to black list particular plugins. Unless it still exists and is just currently undocumented, our only option will be to build an equivalent to the es2015 preset ourselves. Not exceptionally difficult, but it will add to our overhead as the preset changes over time.

it's a lot slower than native generators.

Do we have good data on that? (I believe it, just curious).

[jamestalmage]

Hmm - I'm seeing a blacklist option here, wonder if that is babelify specific or not. Need to check it out.

[sindresorhus]

- 'npm i -g npm@latest'

[sindresorhus]

There's something mentioning blacklist here: https://github.com/babel/babel/blob/59f5e7f218ffa788e6e3f320a3e7e0cbe6d50894/packages/babel-plugin-transform-runtime/src/index.js#L14-L22

Or maybe we could just do a PR to babel-plugin-transform-runtime to only add the regenerator include when needed (based on has-generator).

I would prefer we didn't have to maintain our own preset.

[jamestalmage]

transform-runtime would not be the right place. That only transforms what would otherwise be polyfilled globals into require statements to avoid polluting the global namespace:

var x = new Promise(...)
// => 
var runtime = require('runtime');
var x = new runtime.Promise(...);

I think it would need to be an config param to babel-preset-es2015 (can you even pass config params to presets?), or to whichever module would be the appropriate target for a blacklist option. Probably something near or around the OptionManager class; it looks like it does some work loading/configuring plugins.

I would prefer we didn't have to maintain our own preset.

Yeah - that was my feeling.

[sindresorhus]

I think it would need to be an config param to babel-preset-es2015 (can you even pass config params to presets?)

I read somewhere on the Babel issue tracker they would be open to that.

[sindresorhus]

A lot of stuff are blocked by Babel 6 support. I'm trying to think what's the minimum we can do to land this? Maybe we can just have regenerator even for newer Node.js version and open a ticket about submitting an option to babel-preset-es2015?

[jamestalmage]

Maybe we can just have regenerator even for newer Node.js version and open a ticket about submitting an option to babel-preset-es2015?

👍

[sindresorhus]

Done: #348

@jamestalmage Anything else before we can merge this?

[fernandofleury]

Any feedback when this feature might be finished? Any points we could help?

[jamestalmage]

Anything else before we can merge this?

That depends on our priorities. It breaks Babel 5 support (You can't use babel-5 to instrument your production code). I have no good solution for that.

Perhaps we could simply detect which Babel version resolves for a given test file, and then conditionally provide a Babel6 or Babel5 config based on what we find.

Or we just rip off the band-aid and go for Babel 6.

[sindresorhus]

Or we just rip off the band-aid and go for Babel 6.

👍 I'm not too concerned with that as Babel 5 is not supported anymore and people will have to upgrade sooner than later and they can just stay on AVA 0.8.0 in the meantime.

[sindresorhus]

Landed. Yay! :)