ESLint v5 Wish List

[btmills]

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.

[platinumazure]

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).

[platinumazure]

Also, implementing #7443 (warnings on deprecated rules) would be awesome.

[not-an-aardvark]

• Linting files in parallel (Lint multiple files in parallel [$500] #3565) would benefit a lot of people.
• Allowing parsers to hook into scope analysis (Update: Improve parser integrations (fixes #8392) #8755) would make it much easier for parsers to support custom syntax.
• Allowing autofixes in preprocessors (Autofixes in processors #7510) would make them much more useful -- adding a preprocessor currently imposes a high cost on the user.
• Eliminating the behavior change between local and global installs (Local vs. Global installation #6732). In my opinion, the distinction has caused more confusion than it's worth.
• Dropping support for Node 4, as it's no longer in LTS. This would allow us to use packages that support Node 6+, and we could also use more ES6 in our codebase.

Stretch goals (on my wishlist, but not sure they'll get done by v5.x):

• Creating a better way to include plugins in shareable configs (Support having plugins as dependencies in shareable config #3458)

• Creating a better API for autofixes that modify the AST. With our existing text-based autofix API, it's extremely difficult to write a correct autofixer that modifies the AST, because there are so many cases to handle. You have to make sure that the fix (a) doesn't affect precedence, (b) doesn't combine two tokens into one as a result of no spacing, (c) doesn't combine two statements into one as a result of ASI, (d) doesn't cause some code to become a comment, (e) doesn't put illegal nodes such as function expressions at the beginning of a statement without parenthesizing them, (f) doesn't cause a statement to become a directive, (g) doesn't create mismatched parentheses if a fixed node is parenthesized, (h) doesn't remove a node from a location where it's required, ... etc.

  I'm imagining that we could create something like the Babel plugin API to make modifications to the AST and handle formatting automatically.

[aladdin-add]

• Per-rule autofixing(Discussion: Per-rule autofixing #8018 Request: a way to disable autofixing for no-debugger #8695 feature: ability to disable autofix for specific rules #8935 An easy way to disable --fix rules #8949 support disabling specific rule fixes #7549 --fix with rule option #8479 Allow more control over fixes in CLIEngine #8039): this is useful to some editors.

[ilyavolodin]

All of the things mentioned above plus a few additional things:

1. Most of the editor integrations don't use our APIs, and instead build wrappers around CLI (at least that's what I've heard). I would like to understand what's missing from the API and how we can improve it to make it easier to integrate with ESLint.
2. I think we need to spend some cycles on performance enhancements. We've neglected that aspect for a while, and to be honest ESLint is madly slow on large repositories. We can start by restoring our NPM perf script.
3. Now that glob configs are in, I think we need to rethink preprocessors and how they are registered.
4. I think maybe it's time we start thinking about breaking ESLint into smaller packages. @nzakas had a (very) long term vision of breaking ESLint into reusable parser/linter that can be used as a base for other linters. I think would could think about even smaller chunks that can be broken off. Like config management and loading.

[fgarcia]

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

1. Potential errors
2. Code style / beautification

I wanted an easy way to run ESLint in one of those two modes. I assume that all --fix rules are about code beautification. In my workflow I want (1) before commit and (2) while editing.

Obviously I fixed this by disabling one by one every --fix rule. I try to use ESLint to beautify my code (2), not to force me to beautify my own code.

Personally I even believe that per-rule autofixing will add more complexity than needed. Mostly because I have two workflows where having --fix rules is all or nothing.

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

[platinumazure]

@ilyavolodin

Most of the editor integrations don't use our APIs, and instead build wrappers around CLI (at least that's what I've heard). I would like to understand what's missing from the API and how we can improve it to make it easier to integrate with ESLint.

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.

[ilyavolodin]

@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.

[not-an-aardvark]

Actually, the Atom integration does use the Node API as of a few months ago (AtomLinter/linter-eslint#873)

[not-an-aardvark]

I would like to understand what's missing from the API and how we can improve it to make it easier to integrate with ESLint.

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.

[j-f1]

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:

• Different literals have different node types. For example, 2 is a NumericLiteral, while "foo" is a StringLiteral
• foo () {} in { foo () {} } and foo: function () {} in { foo: function () {} } are different types of node.
• New JS feature proposals are supported, which means that people will be able to write lint rules for them.

Also, babel-types is awesome.

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

• RegExpLiteral (ESTree): The pattern and flags properties are moved to the root of the node, instead of inside a regex property. This could be made backwards-compatible.
• NullLiteral, StringLiteral, BooleanLiteral, NumericLiteral: Split out from Literal. Somewhat backwards compatible — the Literal listener can be called with the old node, while the *Literal types can be called with the new node.
• Program (ESTree), BlockStatement (ESTree): New directives key
• ForOfStatement (ESTree): New await key.
• AwaitExpression (ESTree): argument becomes optional 😕
• ObjectExpression (ESTree): properties can have ObjectProperty | ObjectMethod | SpreadElement
• ObjectProperty, ObjectMethod: Split from ESTree’s Property (ES6 changes). They have decorators, and kind is slightly different.
• MemberExpression (ESTree), CallExpression (ESTree), NewExpression (ESTree): New optional property
• CallExpression (ESTree): callee can be an Import node
• TemplateElement (ESTree): value.cooked can be null
• AssignmentProperty (ESTree): kind is gone, the node now has a type of ObjectProperty instead of Property
• ObjectPattern (ESTree): properties can include RestElements
• Class (ESTree): New decorators property
• ClassBody (ESTree): Body can contain ClassProperty | ClassPrivateProperty
• ClassMethod (ESTree: MethodDefinition): is a Function, instead of having a FunctionExpression in value; new decorators property

New:

• Decorator
• Directive
• DirectiveLiteral
• Import
• BindExpression
• DoExpression
• ClassProperty
• ClassPrivateProperty

[nzakas]

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.

[pvdlg]

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.
A search for eslint-config-* on NPM returns 3047 results as today !

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.

[nzakas]

Some of my wishes:

1. I'd like to move style-related rules into a plugin. It seems like there's the most thrash on those rules, so would be nice to separate them out. We could still ship with it included for back compat for a while if necessary.
2. Similarly, id like to move the CommonJS/NodeJS specific rules into a plugin. As the world increasingly moves towards async functions and ES modules, these will become less useful to the general population of devs.

[j-f1]

2. Similarly, id like to move the CommonJS/NodeJS specific rules into a plugin. As the world increasingly moves towards async functions and ES modules, these will become less useful to the general population of devs.

eslint-plugin-node might be happy to accept those rules.

[nzakas]

@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).

[aladdin-add]

closing as eslint v5 has been released.