Babel feature detection

[ariporad]

This fixes #348. It uses babel-preset-features to auto-detect ES6 features. Also includes tests.

Enjoy!

[ariporad]

Grr... A dependency has a require with an uppercase letter, which is killing travis. I submitted a PR, but the author is on the other side of the world. Give it a few hours, then it should be ready.

[sindresorhus]

I like the idea, but I'm a bit wary of it. What if the native implementation has bugs and we want to use Babel for that? What is the runtime overhead of doing a bunch of feature detections? And https://github.com/hax/babel-features doesn't look very actively maintained nor used much https://www.npmjs.com/package/babel-features.

I just don't want this to cause us a lot of extra overhead with support issues, etc.

// @hax

[ariporad]

@sindresorhus: Check the 2.x (currently in beta) branch, it was last worked on 5 days ago 😉. It even already supports Babel 6.

I think there's a little overhead, but not a whole lot. I'm not sure how we'd go about it any other way, regardless. And I guess we'd just assume that V8 isn't going to ship something horrifically broken. The overhead is going to down once we move babel to the main thread.

[sindresorhus]

I think there's a little overhead, but not a whole lot. I'm not sure how we'd go about it any other way,

We could create a preset for each Node.js major version →#148. Albeit that won't work when we eventually add browser support → #24.

And I guess we'd just assume that V8 isn't going to ship something horrifically broken.

They do all the time. That's the price for rapid evolution.

The overhead is going to down once we move babel to the main thread.

That's a good point.

[hax]

Sorry I have cold last week and not check the github notifications.

What is the runtime overhead of doing a bunch of feature detections?

The runtime overhead of feature detection < 10ms, so I think it's ok for most applications.

What if the native implementation has bugs and we want to use Babel for that?

Yes they have. But Babel also have 😀 . So we need to check it case by case. For example, whether to use regenerator. (node 0.12+ have generators, but missing some minor features such as Generator.prototype.return. babel-preset-es2015-node-5 decide to not use regenerator. If there is any other case like that please let me know.)

[sindresorhus]

There's also the case of many of the ES2015 features being a lot slower than the transpiled ones.

[hax]

@sindresorhus
This is due to V8 (and other implementations) seem focus on es2015 features not performance up to now. Even simple const/let could cause deoptimization.

But I never see a real case such performance degradation is significant for a webapp (browser-side) in my daily work. Maybe heavy-load Node.js apps would affected by it. Anyway they can just switch from babel-preset-es2015-node-* to normal babel-preset-es2015.

[jamestalmage]

My vote is to punt on this until a later date. AVA and Babel both are currently moving at breakneck speed. I would prefer not to introduce an extra layer of complexity.

[novemberborn]

Closing due to inactivity. #148 is the issue for this feature. Would love your help if you have the time @ariporad!