Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Don't use regenerator in babel-preset-es2015 for newer Node.js versions #348

Closed
sindresorhus opened this issue Dec 21, 2015 · 11 comments
Closed

Comments

@sindresorhus
Copy link
Member

Split out of #333.

Only Node.js 0.10 needs regenerator, but it's currently included for any Node.js version.

Someone needs to do a pull request to babel-preset-es2015 and auto-detect generator support and conditionally include regenerator (preferred solution) or add an option for toggling regenerator.

// @thejameskyle @jamestalmage

@thedev
Copy link

thedev commented Dec 21, 2015

What do you think about using a post install script ?
Noticed the following discussion: npm/npm#7340

@sindresorhus
Copy link
Member Author

@thedev This isn't about having regenerator as a dependency. We just don't want the runtime overhead of using regenerator when it's not needed for newer Node.js versions which supports generators.

@jamiebuilds
Copy link
Contributor

Someone needs to do a pull request to babel-preset-es2015 and auto-detect generator support and conditionally include regenerator (preferred solution) or add an option for toggling regenerator.

The Babel preset would not accept a pull request for that, just because the environment that is running Babel supports generators does not mean the targeted environment will.

If you want to create a preset babel-preset-node-feature-detection that tests for support for everything before running it, that would likely be the best solution. However, it should warn heavily that you should not distribute the generated code with it (we don't want npm filled with node version specific modules).

@sindresorhus
Copy link
Member Author

@thejameskyle That's a good point. I just considered our case of live transpiling. Would you be open to add an option to the preset for toggling regenerator? We really don't want to have to maintain our own presets.

@jamiebuilds
Copy link
Contributor

@ariporad
Copy link
Contributor

@sindresorhus: Check out hax/babel-features. I'll turn it into a preset if you want. Or we could just use it directly.

@ariporad
Copy link
Contributor

@sindresorhus: Actually, I went ahead and turned that into a preset anyway: babel-preset-features. It's a drop-in replacement for babel-preset-e2015, I'll submit a PR.

@tmaximini
Copy link

I ran into the same issue, went with https://github.com/alekseykulikov/babel-preset-es2015-node5 for now

@jamestalmage
Copy link
Contributor

@tmaximini What issue? The only difference should be one of performance. If you've got other issues let us know.

@novemberborn
Copy link
Member

Closing in favor of #148.

@buzinas
Copy link

buzinas commented Apr 8, 2016

@jamestalmage performance always matters, and it's always good to have as much as possible a generated code side-by-side with the source one.

If we have native support, we should always use it, there is absolutely no reason to use something ugly and gross on top of something that already exists and performs well.

I can understand people using bluebird instead of the native Promise, for example, but using a feature like regenerator, only if targeting browsers.

Another great difference: Debugging is terrible with regenerators, and it's awesome with native generators.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

8 participants