Eslint: ESLint 2.0.0 Wish List [$10]

[nzakas]

As we are getting closer and closer to v1.0.0, it's time to start thinking about what a v2.0.0 would look like. Here are the things that have either come up recently or have been on my mind:

• Autofix option - This has come up at least three times as a request. Originally I was pretty against it, but I'm starting to warm up to the idea. The idea is optionally fix certain types of issues instead of just reporting them. While this won't be possible for 100% of the rules, even a small percentage could make a big difference.
• Autocreate config by looking at code - We need a way to make it easier to get started. Manually configuring over 100 rules is a painful process. It would be nice to be able to give ESLint a file and say "create me a config that matches the styles in this file".

What other ideas do you have about big things we could tackle for 2.0.0?

Did you help close this issue? Go claim the $10 bounty on Bountysource.

[nzakas]

I should note: I'm not saying these are definitely in, just things that have been top of my mind and warrant some discussion.

[ilyavolodin]

I would probably still want support for selectors in the core. Would make writing plugins quite a bit easier.
Other then that, the only thing I can think of is trying to modify espree to handle incomplete code better, so editor plugins could do validation as you type.

[michaelficarra]

Autocreate config by looking at code

This is probably better left to a separate project.

[ilyavolodin]

Agree with @michaelficarra That could be a separate project under ESLint org. I would also add that I don't think ESLint should autofix the code. It could provide suggestions and enough information to some other tool to rewrite the code, (like modified AST), but I think it should be another tool that actually does code output.

[michaelficarra]

Agreed about just providing suggestions. In fact, I had assumed that's what @nzakas meant.

[nzakas]

Selectors are a good one! +1 for that.

I was actually thinking that configuration detecting would be part of the core. The rain is that trying to keep two utilities in sync with regards to rules would be difficult. The way I'm thinking about it : the rules already can detect this information, we just flag the negation of an expectation. We could run the rules in a different mode and have them report what they found instead (context.detected("always ") instead of context.report(), for example).

[ilyavolodin]

You could still do it as a separate tool, that just runs ESLint CLI and processes error messages. If we implement a way for rules to report all of their options, it can collect that and check error messages against rules schema.
However I think it's going to be more complicated then that. Just because ESLint found a few use cases where you used double quotes, doesn't mean that you want to use double quotes everywhere. Might've been just a mistake. So it should be collecting about passed validations vs failed validations and then figuring out which one was intended.

[nzakas]

Yeah, it can be more complicated - but let's not debate implementation details here. Let's just focus on high-level things we'd like to consider.

[ilyavolodin]

How about this: remove styling rules from ESLint and make JSCS a dependency and use their styling rules? Sort of like a special case plugin. I know it's a bit out there, but there are so many preferences for styling that keeping all of them available and up to date will probably take the biggest chunk of everyone's time.

[nzakas]

That's pretty out there. :) I'm not sure I can rationalize outsourcing a big chunk of our functionality to another utility. Plus, we'd still be stuck in a maintenance issue of keeping up with whatever changes are made.

A somewhat less radical (but still radical) thought: what if we exported _all_ of our rules into plugins so that the ESLint repo is just for the core and rules are always handled through plugins? (This thought has crossed my mind...still not sure I like the idea.)

[gcochard]

I think npm's peerDependencies needs to be improved before exporting all rules as plugins. I get a warning (and nonzero exit code) any time I npm install -g anything because two plugins are fighting about eslint's version.

In addition, this might create a lot of verbosity or naming collisions. Which plugins get first class rule names and which need a prefix for example?

[lo1tuma]

A somewhat less radical (but still radical) thought: what if we exported all of our rules into plugins so that the ESLint repo is just for the core and rules are always handled through plugins? (This thought has crossed my mind...still not sure I like the idea.)

This idea crossed my mind as well. Generally I like this approach, we could officially maintain those plugins in the eslint organization. The biggest advantage of this would be the release management, we could make breaking changes to rules without the need to release a new major version of eslint.

[lo1tuma]

@gcochard I thought that’s already on the roadmap of npm v3.

[nzakas]

There's definitely some nice effects from splitting all rules into plugins, but it also complicates releases. For instance, how do we account for rule documentation? There is overhead related to doing releases, so if we end up needing to do 7 releases instead of 1, do we have enough people who would want to manage those? (It would be way too much for me to manage on my own.)

So, we can definitely explore that idea, we just need to be sure to really dig into the logistical issues it would open up.

[gcochard]

@lo1tuma Oh yes it is, awesome! :clap:

[ilyavolodin]

Another thing that I would like to tackle early on after 1.0.0 release (probably before 2.0.0) is refactoring eslint.js and extracting everything that has to do with configuration from it. There's a lot of code that just tweaks config based on comments and so on, and it really shouldn't be in the eslint.js. Not specifically a feature, mostly just cleanup, but I think it's necessary.

[lo1tuma]

@nzakas good point, maybe the eslint site should be able to display the documentation of any plugin (if there is any), but that would be beyond static site generation.

Another feature I would like to see in eslint is to make it possible to apply a configuration based on a glob pattern. Sometimes I'm in the situation where I can’t organize my files in a way so that everything can be configured precisely with the directory hierarchy. For example given the following directory structure:

• /project
  
  
  
  • index.js
  
  
  • /app
  
  
  • app.js
  
  
  • /components
    
    
    
    
    
    • foo.jsx
    
    
    
  
  
  • test
  
  
  • /app
    
    
    
    
    
    • appSpec.js
    
    
    
    • /components
    
    
    
    • fooSpec.jsx
    
    
    
  
  

There is no way to apply specific rules only to *.jsx files without duplicating .eslintrc files to multiple directories (app/components and test/app/components).

[nzakas]

I'm curious if #1637 would help that situation?

[lo1tuma]

As far as I understand #1637 it would not solve my problem, I would still need to create an .eslintrc in every directory where I want to apply specific rules for jsx files, the only content of this file would be the extend or include setting, pointing to a shared jsx specific config file.

[nzakas]

Got it.

[jonathanKingston]

How about a global concessions file, which would allow you to exclude based upon:

• Rule match
  
  
  
  • Regex match rule description
  
  
  • Rule name
  
  
• File
• Line range

If a rule doesn't match then it should also cause an error itself; this gives application managers a centralised place to managing exceptions rather than allowing quick exceptions to a applications styles in comments or other methods.

This is something I have used in work settings and it helps manage governance of coding issues especially if the file accepts comments and ordering.

Advantages:

• Centralised issues/snag list
• Easier management and approval process
• Would add in a global exception rule rather than add to each rule
• When concessions no longer match, the file can also be cleaned due to the error thrown when there are concessions that don't match
• Feature to the platform rather than embedded comments which are mostly ignored

Disadvantages:

• Another whitelist (arguably better than all over)
• Pain point for merges

Alternatives:

• Make comments more flexible and cause errors when not mathing
• Allow for multiple nesting of concession files to ease maintainability

[nzakas]

@jonathanKingston I'm not familiar with this concept and I'm having trouble understanding what you're describing. Is there some place you can point me for more information?

[lo1tuma]

I would also like to see the ability to enable multiple formatters/reporters. This is useful when running eslint on a CI-system like jenkins. I would like to have the stylish report on the terminal AND a checkstyle report written to a file.

[nzakas]

That's interesting!

Another thing I'd be interested in seeing is suffixed .eslintrc files, so you could do .eslintrc.json or .eslintrc.yml to get source code formatting in editors. We could basically look for all the filenames and just use the first one found.

[thefotios]

One thing we came across recently was trying to share .eslintrc files between projects in my company. Right now, we have a separate module with something like eslint/node and then symlink it during grunt build. This process works fine (although I think some of the plugin ideas would greatly solve this problem).

Our issue is that some projects may want to tweak those rules very slightly, but still maintain the same shared style across a company. Based on the order of precedence, this is very difficult. I think if the package.json rules could override the .eslintrc rules (which is backwards from how it happens now), then people could more easily override shared values.

[nzakas]

@thefotios sorry, that's not something we are going to do. It took a lot of work to get the cascade working correctly, we aren't going to change it. Any changes need to _in addition to_ what we already have. Please file a separate issue describing your problem and we can see if there's a way to solve it.

Keep in mind, this issue is for significant changes to ESLint (see other suggestions on this issues).

[btmills]

While we're talking about big changes, what about dogfooding ES6 support by using it in the main codebase? I don't know whether I like this idea since it would require adding a build step, but I'm curious what other people think.

[nzakas]

I'd defer that until we can start using ES6 features without a preprocessor. The preprocessor step adds non-trivial overhead to the debug process (make change, preprocess, run test), even when done automatically. I've dealt with that on other projects and don't want to introduce that here.

So if the whole io.js/Node.js merger/not gets resolved, I'd love to start using the supported ES6 features. For instance, using template strings in rule tests would be huge.

[jonathanKingston]

@nzakas I'm not sure if any of the open source solutions that do this.

However essentially you would have a file (lets call it .esconsessions for now) with the following content:

[
  {
    linerange: [42, 43],
    posrange: [7,8],
    file: 'unit/models/thing-test2.js',
    rule: 'no-console',
    count: 1
  },
  {
    linerange: [43, 51],
    posrange: [0,10],
    file: 'unit/models/thing-test2.js',
    rule: 'no-trailing-spaces',
    count: 4
  },
]

With the following errors:

unit/models/thing-test2.js
  19:0   error  All "var" declarations must be at the top of the function scope  vars-on-top
  21:32  error  Missing function expression name                                 func-names
  23:2   error  'beforeEach' is not defined                                      no-undef
  23:13  error  Missing function expression name                                 func-names
  26:2   error  'afterEach' is not defined                                       no-undef
  26:12  error  Missing function expression name                                 func-names
  30:18  error  Missing function expression name                                 func-names
  32:4   error  Expected indentation of 4 characters                             indent
  34:4   error  Expected indentation of 4 characters                             indent
  35:14  error  Missing function expression name                                 func-names
  38:18  error  Unexpected dangling '_' in '__container__'                       no-underscore-dangle
  39:2   error  Unexpected console statement                                     no-console
  39:6   error  Expected indentation of 6 characters                             indent
  40:1   error  Trailing spaces not allowed                                      no-trailing-spaces
  41:6   error  All "var" declarations must be at the top of the function scope  vars-on-top
  42:6   error  Expected indentation of 6 characters                             indent
  42:7   error  Unexpected console statement                                     no-console
  43:1   error  Trailing spaces not allowed                                      no-trailing-spaces
  46:1   error  Trailing spaces not allowed                                      no-trailing-spaces
  48:1   error  Trailing spaces not allowed                                      no-trailing-spaces
  51:1   error  Trailing spaces not allowed                                      no-trailing-spaces

✖ 21 problems (21 errors, 0 warnings)

ESLint would output:

unit/models/thing-test2.js
  19:0   error  All "var" declarations must be at the top of the function scope  vars-on-top
  21:32  error  Missing function expression name                                 func-names
  23:2   error  'beforeEach' is not defined                                      no-undef
  23:13  error  Missing function expression name                                 func-names
  26:2   error  'afterEach' is not defined                                       no-undef
  26:12  error  Missing function expression name                                 func-names
  30:18  error  Missing function expression name                                 func-names
  32:4   error  Expected indentation of 4 characters                             indent
  34:4   error  Expected indentation of 4 characters                             indent
  35:14  error  Missing function expression name                                 func-names
  38:18  error  Unexpected dangling '_' in '__container__'                       no-underscore-dangle
  39:2   error  Unexpected console statement                                     no-console
  39:6   error  Expected indentation of 6 characters                             indent
  40:1   error  Trailing spaces not allowed                                      no-trailing-spaces
  41:6   error  All "var" declarations must be at the top of the function scope  vars-on-top
  42:6   error  Expected indentation of 6 characters                             indent

✖ 16 problems (16 errors, 0 warnings)

Syntax aside, that is basically how I have seen it implemented at several companies to sit on top of other error checking and ignore issues that tech review have deemed ok despite company policy usually not accepting them.

[nzakas]

@jonathanKingston hmmm, I'm not sure that's appropriate to be built into ESLint. Seems like it would be more useful for an external tool that filters ESLint input.

[jonathanKingston]

@nzakas it doesn't need to be core certainly however it would be good to be within the eslint organisation on github. If there was interest in the community for it that is.

[nzakas]

This is the first I've heard of such thing, so seems like demand isn't all that high. That said, you're always free to start such a project. :)

[puzrin]

About configuring. Users need to read doc site anyway. If they could set checkboxes, pick options and download file, that would save some time. That could be combined with import of existing config.

PS. "Login to doc site via facebook and give like to rules you wish to pick" :)

[nzakas]

@puzrin ah, you mean an online confusion configuration editor? Sounds like an interesting idea.

[puzrin]

@nzakas yeah. Yesterday i've upgraded one project 0.9.1 -> 0.18.0. That was something like this:

• scroll long page with rules
• check if my config has rule or not
• open old ones in new browser tab to check changed options
• open new ones in new browser tab to understand details
• select peaces of text with mouse (rules & options names) and copy to config

Not a big problem for me, but a bit boring for novices, IMHO. If they could do easy config fill in process of documentation reading, that could make them a bit more happy.

[ilyavolodin]

Online configuration for .eslintrc would be nice. We just need to wait for #2179 to land and then do some enhancements on top of it.

[IanVS]

It would be really nice to have some kind of configuration startup tooling. The options seem to be:

• An online generator
• Inspection of existing codebase
• Presets similar to those in JSCS

I recently went through the process of setting up ESLint for the SANE project, and while on the whole it was fairly straightforward, the most painful part was figuring out what the default rules are and what needed to be overridden. I particularly like the idea of an online generator, which could have the default rules "checked" by default to make it clear what you would get without any manual configuration.

I don't know if presets have been discussed in the past, but that would be another way of lowering the barrier to entry and giving people starting new projects an easy way to get going. I don't think it would need to be a 2.0.0 feature, but it seemed to make sense to bring up here with regards to .eslintrc generation.

[nzakas]

Yup, valid points. I think we definitely need some sort of bootstrapping for config files.

We've stayed away from presets in the past to avoid the uncomfortable conversations around whose presets should be included. Rationally, this could be implemented as custom environments, so we are really just talking about finding a way to share environments. At that out, we can let others handle creating presets for common style guides.

[IanVS]

I'm not sure I exactly follow what you mean by sharing custom environments. Are you saying you would not want to include presets within the ESLint project, similar to JSCS: https://github.com/jscs-dev/node-jscs/tree/master/presets? Maybe there could be a separate repo within the ESLint org which contains community-supplied presets (e.g. eslint/eslint-presets)?

Why would conversations about including presets be uncomfortable? To me, the value of presets would be the ability to grab a .eslintrc which has already been set up with rules that match a given style guide. As a consuming developer, there would be no downside to having a plethora of such guides to choose from--it would just be up to me to decide which one to use. Is there a downside on your end to including a wide variety of style guides?

My apologies if this is getting off topic for this issue. I'd be happy to submit an issue to bikeshed there if you'd prefer.

[ilyavolodin]

@IanVS I think what @nzakas is talking about is ability for plugins to create custom environments and configure built-in rules. This way, if somebody wants to create airbnb style, all they have to do is create a new plugin called something like eslint-plugin-airbnb and publish it on npm. Then everyone who will include that plugin into their .eslintrc file will automatically configure all of the built-in rules to match airbnb style guide. This way we provide ability to do presets, but we don't have to maintain and/or approve presets that people come up with.

[nzakas]

@IanVS The downside is that we end up needing to manage, maintain, update, etc. style guides for other organizations. At some point we'll need to cut off exactly which style guides are appropriate to be bundled, and then conversations start getting uncomfortable. Why isn't my style guide good enough to be in the core? It's just not worth the trouble. It's the same with our support of JS libraries, which is to say, we don't really have any built-in support for library-specific functionality.

I'd rather have AirBnB be able to configure and distribute their own config file, Google do the same, Facebook do the same, etc. That way we stay out of those conversations completely.

[IanVS]

That makes a lot of sense. Thanks for taking the time to explain.

[teppeis]

:+1 for autofix. I use Closure Linter and recent JSCS for this feature in addition to ESLint.
If ESLint has autofix, we don't have to use other lint tools and many duplicated configuration files.

[joeybaker]

I'd like to add a vote for the "autofix" option, but I'd like to discuss the API. It would be nice to have several ways to implement the feature.

1. Add a option in .eslintrc. Something like autofix: true should do it. This would automatically be applied on every run of the linter.
2. A flag on the command line.
3. An option on the programatic API.

[nzakas]

We aren't discussing implementations here, only ideas. If something is added to the roadmap, there will be a separate issue filed to discuss implementations.

[ilyavolodin]

While not exactly a feature, but I would suggest that we should take a much closer look at documentation for 2.0. Currently we have a lot of information in documentation, but it's not easily consumable. It's hard to find things and even harder to read through pages upon pages of text to locate needed information. I really think that should be one of the top priorities.

[nzakas]

@ilyavolodin that's a great idea.

[glenjamin]

Not sure if this is really a 2.0.0 thing, but I think having plugin discovery part of the website would be awesome.

The unit of sharing & discovery is a plugin, but the unit of configuration is a rule - so having a standard way for plugins to export documentation about their rules which could be pulled into a searchable site would be awesome.

Another cool thing for discovery would be the ability to type some JS into a box, and have a website tell you all of the core & plugin rules that would disallow it (this gets tricky with config!).

In theory these could drastically reduce the number of issues and discussions on rules in this project.

[xjamundx]

@glenjamin really love the idea of better plugin discovery. my assumption is more that it would hook into NPM and rely on people tagging things properly.

I'd also love to find some better / easier way to explain how the various rules work. There are just so many of them now. Something like https://babeljs.io/docs/learn-es6/ but for rules might be interesting?

So many good ideas in this thread. I think breaking out the rules as plugins is interesting....more thoughts coming soon!

[ilyavolodin]

Here another idea for 2.0.0
To improve performance of eslint, we could change the code to use thread-pool of web worker threads, and run each file in it's own thread. Mostly everyone has a multi-core processor at this point, so we should get a pretty significant boost in performance.
In order to do this, however, we will have to make everything up to cli-engine.executeOnFiles async and use callback pattern (or promises).

[xjamundx]

To fill in some of the "make everything a plugin" talk. I could see us splitting the rules into a few plugins, for example all of the spacing rules, could easily make sense as their own plugin. All of the ES6 stuff another plugin, etc. At this point there are many rules and they become hard to follow, splitting them into logical groups might help for a lot of reasons.

[nzakas]

@xjamundx unless you have a plan for the logistics around that (see my earlier comment), it's going to be hard to do that.

[doberkofler]

@nzakas Based in the start of this discussion, I just wanted to mention, that jscs now actually support an auto configure (--auto-configure) and auto fix (-x) option.

[nzakas]

Yup, just noticed auto configure, but have no idea how it works.

[doberkofler]

@nzakas It basically test one or a set of files against all (pre)configurations and shows the number of errors in each configuration:

jscs --auto-configure Gulpfile.js
Checking Gulpfile.js against the presets
   Preset           #Errors #Rules
1  airbnb           261     8
2  crockford        184     2
3  google           253     4
4  grunt            226     4
5  jquery           782     9
6  mdcs             116     5
7  node-style-guide 326     9
8  wikimedia        511     8
9  wordpress        505     8
10 yandex           210     6
Please choose a preset number:

[ilyavolodin]

That's basically the same approach as this one: https://github.com/willklein/dryer

[vvo]

About autofix option, would https://github.com/millermedeiros/esformatter help?

[nzakas]

@vvo No, as you must configure every option for esformatter to make it turn out correct. What we want is the ability to fix only specific things, not need to reformat the entire file.

[nzakas]

Okay, lots of good ideas here. To get this ball rolling, if like to propose the following as the roadmap post-1.0.0.

1. Auto-fixing (lead: @nzakas)
2. Glob-based rule config (lead: @lo1tuma)
3. AST query selectors (lead: @ilyavolodin)
4. Suffixed .eslintrc files (lead: ?)
5. Create config by looking at code, maybe see if Dryer would be interested in merging into project (lead: ?)

This is just a straw man, what do people think? @eslint/eslint-team

Keep in mind, we can always continue to add good ideas to the roadmap.

[IanVS]

I'm not sure I'm qualified to lead, but I'm pretty interested in the auto config creation project. I'd be happy to at least help out on it where I can.

[nzakas]

Qualification is the willingness to do it, so you're definitely qualified. :)

[ilyavolodin]

@nzakas How about multi-threading support? I think that could give a nice boost to performance, but would require some major changes in the codebase, I'd rather tackle it sooner then later.

[willklein]

Regarding auto-configuration, I would be happy to merge dryer into the project. It spun out of doing config-by-hand (scratch my own itch). I am hearing that it's a post 1.0 goal, but I'm planning to get it fully usable in the next month.

Also, one point of clarification vs jscs --autoconfigure: dryer doesn't look at any presets, it tests and configures each individual rule.

[ariporad]

I'd just like to +1 on the autofix... I'm really not psyched about fixing 600 errors.

[IanVS]

@ariporad: eslint-nibble tries to make it easier to ease into ESLint by letting you focus on one rule at a time, instead of having to bite off 600 errors at one time.

[nzakas]

@ilyavolodin yeah, definitely!

@willklein that would be great. The reason we said post-1.0.0 is due to the various rule changes (#1898) coming in 1.0.0. We'd want to ensure those are incorporated.

[royriojas]

Hi guys any plan to support globs and only operate on files that have changed since last run?

• The globs are nice since it is a more simpler way to ignore certain matches
• Operate on modified files could reduce the time to lint a large code base from seconds to milliseconds (the second time since the first time it will create the cache) without the need for a watch mode over the files.

I have written a module eslinter that does both things but it would be nice to support that in eslint directly.

[ilyavolodin]

@royriojas globs support is schedule after v1.0.0 Interesting idea about caching... I'm not 100% how often that would be used though. You would only get performance improvement if you run eslint on large repository often. I usually run it only once per push, and in between I just run ESLint through editor plugins on a single file.

[royriojas]

In the current project I run the tool over an average of 300 files. it takes 8 seconds to finish. With the cache the time is reduced to the order of milliseconds (depending on how many files are changed).

As part of our workflow the process also beautifies the files (I'm using esformatter and configured it to match the format expected by eslint), that process also takes about 8 seconds without the cache, even when the files were already beautified. That's why I decided to try to find a solution for that and wrote esbeautifier which also only beautifies the files that changed. In both cases the cache really helps! I know 16 seconds doesn't seen that bad, but why wait?

[royriojas]

And what about passing arguments to the formatters? currently the cli parser will strip all the arguments that don't recognize. Maybe defining them in the .eslintrc file in a property with the name of the reporter? I have solve my use case by adding a couple of environment variables but that somehow seems to be more a like a hack than a proper solution.

would love to see a way to pass arguments ;)

[remkoboschker]

+1 for a watch option

[ilyavolodin]

@royriojas We wouldn't be able to pass arguments through .eslintrc, as there might be many .eslintrc files, but there's always only one formatter. We might be able to do that through CLI options.

[nzakas]

@royriojas can you open a new issue about this? It sounds interesting, and I dont want to lose the discussion amongst everything else in this issue.

[royriojas]

@nzakas which one? the cache or the globs?

[ilyavolodin]

globs are already on the tentative roadmap, so I'm guessing it's cache.

[nzakas]

Cache, yes

[royriojas]

thanks @ilyavolodin! @nzakas here it is: https://github.com/eslint/eslint/issues/2998

[mysticatea]

Is there the person who is interested in i18n?

I'm interested in Japanese translations for warning messages and documents.

[nzakas]

Ooh, that would be interesting!

[btmills]

i18n would be really cool. @ilyavolodin's work in #2861 to separate error messages from implementation would help with that.

[BYK]

I may be able to help with i18n.

[confiks]

I might be able to help as well with adding i18n to eslint. I'm interested in it mainly for educational purposes, specifically coding in Dutch middle school, where the students only have a very basic understanding of English.

I've looked through PR #2861, and I understand there are some concerns about where the translations should live, and the need for a more thorough proposal for i18n in eslint. I'd need to familiarize myself with eslint's structure more before I'd be able to contribute.

[BYK]

I understand there are some concerns about where the translations should live, and the need for a more thorough proposal for i18n in eslint

The path we chose at where I work was to treat translations as a dependency and use Transifex as our "translation manager" just like many projects use npm for their code dependencies. The model has been working for us quite well for almost 2 years now.

[nzakas]

Thanks for all the brainstorming! I've consolidated this discussion into #3561, our official 2.0.0 roadmap.