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
Update codebase to use ES6 features supported by Node 4.0 #6407
Comments
Keep in mind that Node 4 doesn't fully implement ES6, so we're still left with a subset of features we can use. I'd like to propose that we focus on using features that can be checked with our existing rules so we can maximize the dogfoodiness of ESLint. I think the easiest to start with are |
Sure, it's the reason I suggested It sounds good that we enable those 2 rules to start. |
Wondering if this is worth turning into a milestone, and then we can propose individual features we want to start using as individual issues? (For example, someone could create a rule for "use let/const" which would involve turning on no-var and prefer-const and fixing the resulting lint warnings, and that issue would be added to a "use-es6" milestone.) |
I think that's overkill for right now. Let's keep the conversation here until we have some good conclusions and we can figure out next steps after that. I'd really like to start using classes, as well. |
Does someone with some good familiarity with the capabilities of node@4 want to put together a list of current ESLint rules which we could enable, then we can narrow them down from there? |
@IanVS here you go, a list of all ES6 eslint rules that we could enable for node@4, split by feature: Arrow functions
Generators
Template strings
let/const
Object literal extensions
Classes
|
@vitorbal I checked some rules which have been enabled by |
@mysticatea Note that our repository does not use Well, although that should extend |
We use Thanks @vitorbal for the list. I think we should use all of these. :) What do others think? |
Is the assumption that we're using the default configuration for all of them? If so, using them all is fine by me. I'm 👍 for |
The stylistic rules need to be discussed, as i don't think just accepting defaults without discussion is a good idea. |
Ah, okay - thanks, makes sense |
I tried converting a single file to use |
Yes, PhantomJS is hopelessly behind. Are there other test runners we should be considering? |
Why are we using PhantomJS? Unless we're using it to test the browser version (which would require us to transpile anyway)? |
@mikesherov We have tests for web version of ESLint for website demo. The code is not really transpiled, it's currently just browserified. But if we are starting ES6, we might have to transpile it anyways. |
This is my point exactly. ^ If we are going to test and distribute a browser version, we need to transpile regardless. |
@mikesherov Ah, I think you're saying we can keep using PhantomJS as long as our selected transpiler transpiles to an ES5 that PhantomJS can work with? |
Agree. Although I hate transpiling, but not much choice here, really. |
Ah! |
I'd like to hear some other options before going to transpiling. For instance, does anyone know if a PhantomJS version exists with ES6 support? What about the new headless Chrome? And what do we want to say is our browser support level for the demo? |
Some statistics:
This is for traffic from March 1, on all pages of the site (not just demo). |
@nzakas Looks like it's in progress ariya/phantomjs#14366 and headless chrome is not ready yet? |
PhantomJS v2 (current version) doesn't support ES6 features at all... |
I tried throwing babelify into my local setup and it worked pretty easily (literally the first time). So, seems like that may be the way to go. |
Yikes, this thread is getting really huge. I'll try avoid force pushing so much to try to keep this issue easier to manage. Wanted to follow up and see what everyone else thought about enabling the final rule in my comment above, which is |
I'm 👍. More rules, more fun. :) |
Continuing the discussion started in #6356, it would be awesome to upgrade our codebase to benefit from ES6 features that are available after dropping Node < 4 support.
Below are some of the ideas already mentioned:
@mikesherov:
@ilyavolodin @platinumazure:
@mysticatea:
The text was updated successfully, but these errors were encountered: