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
ESLint v5 Wish List #8972
Comments
I'd like to see if we can get rule messages into metadata (see #6740-- concept has been accepted and is on core roadmap, but hasn't been important enough to get onto a major version milestone yet). |
Also, implementing #7443 (warnings on deprecated rules) would be awesome. |
Stretch goals (on my wishlist, but not sure they'll get done by v5.x):
|
All of the things mentioned above plus a few additional things:
|
I am the the OP #8949 and as mentioned in the comments my request was not about per-rule autofixing My concern is that ESLint serves two purposes
I wanted an easy way to run ESLint in one of those two modes. I assume that all Obviously I fixed this by disabling one by one every Personally I even believe that per-rule autofixing will add more complexity than needed. Mostly because I have two workflows where having After reading the comments I understood that my workflow / need is quite rare, so I did not want to discuss the topic further if it has little value for others. However if that issue is added to a wish list, I would insist again that it is not about "per-rule autofixing", I am against that. My wish is about having an easy way to split two tasks: error detection vs beautification |
How much of that, in your view, is actually lack of API surface? Personally, I think it more likely that a lot of editor environments make it easier to invoke shell scripts or commands rather than invoking a Node runtime. |
@platinumazure I'm not really sure, to be honest. I know that both Atom and VSC are capable of using our Node API, but neither of does. I think mostly this is due to performance, but, again, don't have enough information. |
Actually, the Atom integration does use the Node API as of a few months ago (AtomLinter/linter-eslint#873) |
I think we should also improve our documentation. There are a lot of undocumented methods methods in the API, which might discourage people from using it because they might not know something exists. |
I would love to see the ESLint and Babel ASTs merged. This would make ESLint better because new parser features only have to get implemented in one parser, reducing the ESLint team’s workload. The ASTs are mostly compatible, but Babylon’s has a few improvements IMO:
Also, A quick look through the AST shows that many rules would probably continue to work fine, and the ones that don’t should be able to be fixed fairly easily. Changed nodes
New: |
Babel unfortunately uses a nonstandard AST. We use the ESTree format, and Babel early on started out with that format before going out on its own. I'd rather support the standard that is implemented by many projects (Esprima, Acorn, escope, estraverse, and of course ESLint and Espree) as opposed to adopting something that only one tool used. |
ESLint has become the standard for Javascript linting and it is increasingly popular. So much that a very large number of developer/company/organization created their own shareable config. So I'd like to emphasis the importance to find a solution to #3458. Also it's the issue with currently the most comment/reactions, so it's seems ESLint users find it important. This problem is really not easy to solve, so the debate on this issue has been going on for 2 years. But is seems there might be a consensus around @not-an-aardvark's solution proposed here. So v5 might be a good time to tackle this issue. |
Some of my wishes:
|
|
@j-f1 that's exactly what I was thinking. Good to know we are on the same page. Another idea: I'd like to update eslint:recommended with recommendations for post-ES5 code, as I think there are emerging best practices that would be useful to get out there. We can create eslint:recommended-legacy if we want to provide recommendations for ES5 only (though we should discuss if that's necessary). |
closing as eslint v5 has been released. |
In the spirit of previous wish lists, now that v4 has shipped, what big changes do we want to see in v5? We can use this issue for brainstorming and discussing ideas. For the changes we want to tackle for v5, we'll then create issues in the v5.0.0 milestone.
The text was updated successfully, but these errors were encountered: