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

Detect Node 6 in test environment and disable ES2015 transforms #863

Closed
gaearon opened this issue Oct 6, 2016 · 13 comments
Closed

Detect Node 6 in test environment and disable ES2015 transforms #863

gaearon opened this issue Oct 6, 2016 · 13 comments

Comments

@gaearon
Copy link
Contributor

gaearon commented Oct 6, 2016

As mentioned by @cpojer this can significantly speed up the tests. We only need to leave the CommonJS transform from ES6 because Node doesn't support modules yet.

https://twitter.com/cpojer/status/783651892320571394

If you intend to work on this please write in a comment here. If somebody else is already working on it please don't try to beat them. If you later change your mind it's fine but please comment here so somebody else can take the issue.

@gaearon
Copy link
Contributor Author

gaearon commented Oct 6, 2016

Update: @shubheksha will work on this.

@balanceiskey
Copy link

There's a danger, mentioned in the twitter thread, right? Wouldn't this break ES6 style import/exports? I mean I realize it's kind of fake, but if you're trying to keep from writing multiple types of import styles it actually helps to have this on.

@MoOx
Copy link
Contributor

MoOx commented Oct 6, 2016

This might be interesting to look at https://github.com/babel/babel-preset-env

@cpojer
Copy link
Contributor

cpojer commented Oct 6, 2016

It would still require the ES module transform.

@balanceiskey
Copy link

Wow I am blind. It says that right there...

@afaayerhan
Copy link

@cpojer what about async await. if you are a disabling it you would need to document it properly because node 6 does not support async await

@cpojer
Copy link
Contributor

cpojer commented Oct 6, 2016

async/await is not part of ES2015.

@afaayerhan
Copy link

@cpojer was a dummy there was using typescript async await that's why I forgot that async await transform is not applied there

@hzoo
Copy link

hzoo commented Oct 6, 2016

We're working on https://github.com/babel/babel-preset-env right now (and would appreciate help here). This would figure out the correct plugins to run given the environment (browsers/node/etc)

With https://github.com/babel/babel-preset-env/pull/12/files were trying to use https://github.com/kangax/compat-table to get the data. In reading the data I'm finding some missing data for node that people can help fill in compat-table/compat-table#932. I can write up a guide on how to do so as well.

There are also other presets that people have already made (basically turn off plugins and use process.version to detect)
https://github.com/michaelcontento/babel-preset-modern-node/blob/master/index.js
https://github.com/rtsao/babel-preset-es2015-node/blob/master/index.js
and probably others by searching npm

@gaearon
Copy link
Contributor Author

gaearon commented Oct 11, 2016

@hzoo I just merged a PR that uses -env. I assume it's relatively stable/works, even if incomplete?

@hzoo
Copy link

hzoo commented Oct 11, 2016

It should be ok - data is at https://github.com/babel/babel-preset-env/blob/master/data/plugins.json and users can add the debug option to console.log the plugins used.

It's probably more safe than other presets because it checks for 100% implementation before compiling - better to not compile if it implements more than Babel's implementation (another feature).

Would be a discussion in babel-preset-env's issue but what do we do about partial support (90% usecase, strict mode, etc) babel/babel-preset-env#16

Should it just use native if the basics or the feature are implemented? https://github.com/rtsao/babel-preset-es2015-node/blob/master/index.js is very lenient

@gaearon
Copy link
Contributor Author

gaearon commented Oct 11, 2016

We're going to always pick the safest option possible as it's just an optimization.

@hzoo
Copy link

hzoo commented Oct 11, 2016

👍 Might be overkill but it would be interesting to get data on what fails to see what features in compat-table users are transpiling (most likely the non 100% versions would still work).

we should totally do this in babel as well 😄

@lock lock bot locked and limited conversation to collaborators Jan 22, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants