Future wish list

[nzakas]

We are almost ready to release 2.0.0, and as such, it's time to start thinking about 3.0.0. As usual, the goal of this issue is to gather feedback on important changes that would be breaking or ambitious. (Other suggestions can just be filed as an issue.)

We are already looking at dropping support for Node < 4 in 3.0.0.

One thing I'd like to hear is ideas for how can ESLint better support TypeScript and Flow.

Note: keep the suggestions as high-level descriptions. This is a brainstorming exercise, we don't want to get into implementation details or plausibility discussions. Let's just see what ideas people have. The best will be explored further.

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

[ilyavolodin]

Well, I think everything that was planned for 2.0 and not implemented will automatically move into 3.0, which means glob configs, selectors, parallel linting, etc. On top of that, what I would like to have is an investigation into is separating doctrine and jsx parser from the core. It would be great to provide those as parser plugins, so that people who don't care about jsDoc or jsx don't need to spend time waiting for those. It would also allow for other possible formats, like maybe handlebar templates, etc.

I would also like another pass at autofixing. What we have now is great, but very brittle, and only works for a few rules. I think we should also try to expose autofixing to editors (so not autofixing the whole file, but instead doing report first, and then autofixing just the error that was specified), this way editors could have functionality similar to WebStorm/ReSharper, when you not only get notified about errors but you have a nice menu that allows you to fix the issue.

One more item is that I think we need to take another look at local vs. global installation, since it's been confusing users for a while. Would be nice to resolve it in some more user friendly way somehow.

[platinumazure]

On top of that, what I would like to have is an investigation into is separating doctrine and jsx parser from the core. It would be great to provide those as parser plugins, so that people who don't care about jsDoc or jsx don't need to spend time waiting for those. It would also allow for other possible formats, like maybe handlebar templates, etc.

:+1: from me, since that would simplify my microtemplate work.

[jeffmo]

I'd love to spend some time to see if/where Flow can provide any useful bits of its analysis up to ESLint so that plugins can ask for and make use of it. I have some high level ideas around APIs that return maybe-results (depending on presence of a type checker) -- but it would be good to brainstorm a bit.

This would be useful for various lint rules that could make use of types to be more high-fidelity like "Dont use for-in on arrays" or "Don't use strings with setTimeout" or "Call .done() on dangling promises" (etc)

[johnman]

It would be good if ESLint 3 supported typings (Facebook flow supports typings and is used by some). My main preference would be typescript support (which has seen increased adoption over the years). This would mean we could drop tslint and use ESLint regardless of whether it was a JS or TypeScript project.

[nzakas]

@ilyavolodin

On top of that, what I would like to have is an investigation into is separating doctrine and jsx parser from the core. It would be great to provide those as parser plugins, so that people who don't care about jsDoc or jsx don't need to spend time waiting for those. It would also allow for other possible formats, like maybe handlebar templates, etc.

JSX is built into Espree, so separating that out isn't possible. For JSDoc, we could decidecto remove the rule we have now and point people to https://github.com/gajus/eslint-plugin-jsdoc. I think if we roll this up under "decrease download size," we can probably find more packages to remove.

I would also like another pass at autofixing. What we have now is great, but very brittle, and only works for a few rules.

Yeah, I definitely want to take another stab at this.

I think we should also try to expose autofixing to editors (so not autofixing the whole file, but instead doing report first, and then autofixing just the error that was specified), this way editors could have functionality similar to WebStorm/ReSharper, when you not only get notified about errors but you have a nice menu that allows you to fix the issue.

I think this is already possible through the API. Of course, we don't handle editor integration directly, but you can get the results with suggested fixes and then do what you want. Is there something in particular you're looking for here?

One more item is that I think we need to take another look at local vs. global installation, since it's been confusing users for a while. Would be nice to resolve it in some more user friendly way somehow.

Yeah, I'm still not sure if there's a good way to do this (or how necessary it is). But if someone wants to investigate and see if the issues in https://github.com/eslint/eslint/issues/3993 can be addressed, it could be nice.

[nzakas]

@jeffmo

I'd love to spend some time to see if/where Flow can provide any useful bits of its analysis up to ESLint so that plugins can ask for and make use of it. I have some high level ideas around APIs that return maybe-results (depending on presence of a type checker) -- but it would be good to brainstorm a bit.

Happy to have that discussion.

@johnman You can already use Flow through babel-eslint, and we are working on a TypeScript parser: https://github.com/eslint/typescript-eslint-parser

[sindresorhus]

I'd love to spend some time to see if/where Flow can provide any useful bits of its analysis up to ESLint so that plugins can ask for and make use of it.

:+1: I've had many good rule ideas closed here because of missing type information.

For JSDoc, we could decidecto remove the rule we have now and point people to https://github.com/gajus/eslint-plugin-jsdoc.

:+1:

I would also like another pass at autofixing. What we have now is great, but very brittle, and only works for a few rules.

Relevant: https://github.com/cst/cst

One more item is that I think we need to take another look at local vs. global installation, since it's been confusing users for a while. Would be nice to resolve it in some more user friendly way somehow.

We've had great success in AVA with using local version if available when executing the global version. As asked for in #3993. It's very simple to implement: https://github.com/sindresorhus/ava/blob/0e6db13a918f0116927299271d91fff590328cb9/cli.js#L6-L14

[hzoo]

re: autofixing, When we're finished up with cst in JSCS hopefully we take learnings/figure out how to use it in ESLint?

[mysticatea]

@nzakas @ilyavolodin I have a plan to send a PR to add autofixing such as ReSharper to VSCode after this PR was addressed.

This is an early prototype.

I wish to implement autofixing for more rules (e.g. no-var, prefer-const, ...).

[ilyavolodin]

@mysticatea Very nice!

[nzakas]

@hzoo I don't see us using CST in ESLint, it doesn't mix well with our architecture and it would limit us to auto-fixing only things CST supports.

@sindresorhus the big issue we had with #3993 was how to help users differentiate between local and global. Did you look into that at all for Ava? Keep in mind, we have plugins and shareable configs that make our use case a bit more complex.

[lo1tuma]

Maybe this idea is a bit too ambitious but I want at least mention it.

Make the cli-engine a separate project, which would be a generic framework for any kind of linters. ESLint does IMHO an awesome job when it comes to file traversal, configurations and plugins. Those things are not really related to JavaScript and could also be useful for other linters. For example sass-lint has a lot of features in common with ESLint:

Introduce pluggable config (a la ESLint)

Another example would be markdownlint which currently doesn’t have a CLI at all.

The benefit of this would be to have a larger community around the framework/cli-engine and we would probably get more contributions.

[BYK]

@lo1tuma - I think that's a great idea but why limit with linters? I need something similar for a project of mine and was thinking yanking some code from ESLint :)

[nzakas]

@lo1tuma I've actually thought along those lines as well, trying to extract as much from ESLint, making it generic, and publishing it so others could create linters (based on the number of clones we are seeing out there). It would be a massive amount of work, but I think it's feasible.

[nzakas]

Here's another crazy thought: what if we completely do away with the configuration cascading in favor of glob-based configuration in files (already proposed #3611)? I think that eliminating the cascading would make this easier, and it would also allow us to move the contents of .eslintignore into the configuration file.

[lo1tuma]

@nzakas Interesting idea. It would also simplify the implementation of glob-based configuration.

[btmills]

@nzakas :+1: Off the top of my head, a few things moving to glob configuration might improve:

1. Configs can be cached on globs alone instead of some combination of paths + globs, which is where we might end up otherwise, as @lo1tuma pointed out.
2. No longer have to find a clear way to explain "We'll merge all configs up to / unless one contains "root": true then we'll stop there and only if we don't find anything on the way up to / we'll use ~/.eslintrc{.ext} except remember that if your project is under your home directory and you don't specify "root": true then ~/.eslintrc{.ext} will be taken anyway."
3. I expect it'll reduce the complexity of traversal and config merging because we'll have configs defined before we ever get into traversal.
4. As you pointed out, we might not need .eslintignore anymore as long as there's a way to say "don't lint files matching this pattern".

[ilyavolodin]

Interesting idea. On one hand, it has potential to significantly simplify our implementation, on the other, it's a pretty dramatic change, which I'm not sure I'm comfortable with without thinking about it too much. I also feel that glob based configs might not be as flexible for minor differences as cascading.

[nzakas]

@ilyavolodin don't get too wrapped up on implementation details right now, we're just brainstorming.

[mysticatea]

:+1: to eliminating cascading. It would reduce the complexity of traversing and I guess it makes faster.

[nzakas]

Another idea: change formatters so they can stream results: https://github.com/eslint/eslint/issues/4731

[BYK]

:+1: for #4731 - sounds quite useful and a worthy upgrade.

[BenoitZugmeyer]

I would love to see some work on processors. I already raised the issue in #3422 , and have been told that it would require too much work for now, but it could be a nice addition in the future major version. To further illustrate my needs (and apparently I'm not alone #4153 ), I made a tiny prototype of how it could work : https://github.com/eslint/eslint/compare/master...BenoitZugmeyer:plugin-api-prototype . Essentially:

• have a custom way (= not based on a predefined extension list) to trigger processors;
• expose a ProcessorContext in the same spirit as the RuleContext, so we can give more informations to processors, and add some APIs in the future (ex: an API to handle rule fixing inside processors).

Those changes may not be requested a lot, but I believe this would attract more people to write better, more complex processors.

[egoroof]

I wish parser support for async await from ECMAScript 7 because babel-eslint isn't a good solution.

[mysticatea]

Unfortunately, we have started implementing ES7, but async/await dropped from ES7 (probably). I'm really sad :cry:

[sindresorhus]

Browsers are implementing it now regardless. I don't see why ESLint, or rather Acorn, would wait.

[egoroof]

oO didn't know about it. What is the cause?

[ilyavolodin]

@egoroof Timing. It's still stage 3 proposal, but it needs to be stage 4 by March 1 in order to be accepted. It's very unlikely that it will make it.

@sindresorhus object.observe was implemented in Chrome and Opera too. Would not be a good thing to implement something and then have to rip it out.

[michaelficarra]

@ilyavolodin It's not unlikely, it's impossible now. All stage advancement has to happen at a face-to-face meeting of TC39. We don't have any more meetings before March 1.

[sindresorhus]

@ilyavolodin Highly unlikely that will happen to async functions. Object.observe was a more risky bet. But doesn't matter. We have Babel.

[hzoo]

@egoroof babel-eslint would be ok if eslint rules understood async/await syntax. Transforming to es5/es6 is necessary https://github.com/babel/acorn-to-esprima/blob/b20845f56af9a02b4e7ae45a97a53702e480ec34/src/toAST.js#L210-L226 since otherwise other rules would break too. The only current solution is to rewrite rules like in https://github.com/babel/eslint-plugin-babel that can account for async/await in the rules.

[jeffmo]

"Dropped from ES7" is probably better worded as "didn't make the train schedule for ES7". Async/await just didn't meet the formal requirements in time -- but this doesn't mean much about its eventual viability..

Async/await will ship. It's just more likely to be ready later this year than in the next month or two. Getting into the spec is a formality, what matters is what browsers and impls do

[mysticatea]

Sorry, I'm not used to English. Sure, I believe async/await will come to ES8 early.

[nzakas]

Just want to pull back the conversation a bit. This issue is for ESLint features only. What we support language-wise is dependent on what Espree supports and so is not tied to ESLint versions.

[ilyavolodin]

One more thing that I would want to brainstorm is ability to extend default rules. If we are planning to branch out to support typescript and flow, as well as newer features through babel-eslint, most of our built-in rules would not work correctly out of the box. It would be nice to give plugins ability to somehow extend existing rules. Not sure how to do that right, but I also don't want to see core rules have a huge amount of code to support all possible combinations of features. Would be nice to modularize them somehow.

[nzakas]

@ilyavolodin are you talking about just exposing the core rules through an API so people can access them? Or are you talking about more than that?

[hzoo]

@ilyavolodin do you mean like in https://github.com/babel/eslint-plugin-babel/pull/44/files - where we have to clone a rule and modify a part of it to take advantage of an experimental feature?

[ilyavolodin]

@hzoo Yes, exactly. I think even better example would be react rule that marks React as used, so ESLint wouldn't complain about it. @nzakas I think we talked about this briefly at some point. With es7, typescript and flow, we have a lot of deviations from normal rules ahead of us. I would like to at least think about possibility of making it easier for plugins to either provide an override for a built-in rule (worst case scenario), or ability to somehow extend core rule and provide new functionality on top of existing. What I want to avoid is having built-in rules have special cases for es7, typescript and flow. It would be a mess.

[nzakas]

@ilyavolodin I understand the background, Im asking more about what you think is the solution. In my mind, it's kind of already possible to do what you're saying by grabbing a rule file, so I'm wondering what you think a solution looks like. Also worth mentioning: we would basically never be able to remove rules if we did that, so I'm very interested in how you see this working.

[ilyavolodin]

@nzakas I'm not really sure what the solution might be like. Ideally, we would make each rule a "class" with all of the functionality isolated into class methods. That way somebody could inherit from it. And yes, people can currently copy the whole code of the rule and modify it, as @hzoo mentioned, but they can't substitute built-in rule with their own implementation. They can name it the same way, but it would still require plugin prefix. In general, I'm not sure if there's a good solution to this, I just wanted to throw out a possibility out there and see if somebody has brilliant ideas on how this might work. I just really don't want to have core rules to have a bunch of code forks for typescript and flow...

[btmills]

In previous discussions we've tossed around the idea of splitting rules out into separate packages. That approach seems to have worked well for Babel 6. Might that be a small step toward solving the extensibility issue? (Or worth doing even if it doesn't solve extensibility?)

[ilyavolodin]

@btmills Oh yeah, I totally forgot about that discussion. Maybe that would help too. Although I have a feeling that people would then expect us to maintain separate plugins for normal js, typescript and flow at the same time.

[zandaqo]

How about making autofix more flexible by allowing a user to choose rules that she wants to automatically fix or avoid fixing? Not only would it give more liberty to a user, I believe having this ability in core would allow for more aggressive fixes in rules. We can make the current, "safe", fixes applicably by default, and leave optional the more "dangerous" new fixes for the user to opt-in if she wants.

[nzakas]

@zandaqo we can explore letting people indicate which rules to fix. There's a few issues to work through, but seems feasible.

[nzakas]

@btmills we can explore that again. I'm not sure how feasible it is without having dedicated maintainers for each package and a way to aggregate rules onto the site for documentation purposes, but if someone wants to investigate, that seems like an interesting direction to go.

[mathieumg]

@nzakas Regarding @btmills ' proposal, I imagine the core rules would still all live in this repo but get published individually like Babel core plugins. (Automated using https://github.com/kittens/lerna or something alike)

[vjeux]

I'd really love to have a proper integration with github pull requests. I hacked up an integration for react-native but if possible I'd like not to maintain it :p https://github.com/facebook/react-native/blob/master/bots/code-analysis-bot.js

[vjeux]

As @mysticatea gif shows well, I think that the next big step is going to integrate with the editor directly. At Facebook, the Nuclide team is thinking a lot about how to make writing JavaScript better and I hope that there can be some common work to be done between the two projects.

[nzakas]

@mathieumg that's an interesting concept, but keeping all the rules in this repo doesn't give us the type of flexibility we really want with regards to separate release cycles for rules, separate maintainers, separate issue trackers, etc. We've already had a bit of trouble with eslint-config-eslint in this regard, it's unlikely we'll continue down that path.

@vjeux I've seen the bot, but I don't think we have the bandwidth to maintain another project. If you can find a maintainer and want it in the ESLint org, I can definitely arrange that.

[KevinGrandon]

It seems there's been a lot of conversation over in https://github.com/eslint/eslint/issues/3458. It would be great if this could make it into 3.0. It would greatly help the extensibility story of eslint.