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! 👏

[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]

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