Create "eslint:all" to extend from

[jokeyrhyme]

Similar to #2713 .

While you're at it, would it be possible to sneak in an "eslint:all" definition? There are quite a few rules that are disabled by default (pre-1.0), and this would be especially helpful for someone that appreciates strict linters. I fully expect that a few would need to be overridden (e.g. quotes and cyclical complexity), but this would drastically reduce the size of my .eslintrc files.

For example, here is one of my .eslintrc files that turns on all "off by default" rules (with a few tweaks): https://github.com/jokeyrhyme/appcache.js/blob/bdddf7011bf5a3190e26a614adc8f918a2583596/.eslintrc
That's a 26 rule lines in my .eslintrc file that has to be copied and synchronised between all of my projects.

With a way to extend "eslint:all", I'd only have to specify 2 or 3 rule tweaks, which is far more legible.

[nzakas]

If you were using plugins, would you expect all plugin rules to be on as well?

[jokeyrhyme]

If I installed a plugin, then yes I would expect the plugin to be activated. I actually install eslint locally to the project, so each project would only ever have the plugins that I wanted. So in my case, it'd be easier to just override a few settings after extending "eslint:all". This suits me best, YMMV.

I am using the eslint plugin for Atom, which I suppose counts as a "global" install, but I have not installed plugins for eslint against that copy. Maybe if I had globally installed eslint plugins, I might have a problem with "eslint:all", but this doesn't apply to me.

If you think global-install people could be upset with the way "eslint:all" works, maybe it should not include plugins? Or maybe we have "eslint:all-no-plugins" and "eslint:all-with-plugins"?

[jokeyrhyme]

Will it be easy to make up our own definitions that can be NPM installed and then extended?
Maybe an alternative to "eslint:all" is being able to:

1. publish "@scope/my-eslint-rules" to npm
2. npm install @scope/my-eslint-rules in each project
3. in each project: .eslintrc just extends "@scope/my-eslint-rules"

[nzakas]

We have shareable configs: http://eslint.org/docs/developer-guide/shareable-configs

So are you saying that with "eslint: all", you would expect plugin rules to be enabled by default?

[jokeyrhyme]

For me, personally, "all" means everything and the kitchen sink (including plugins and the rules they provide).

But this is just me and my use cases, I have no idea how many other people would want "all" and how many of those would be upset with what suits me best. /shrug

@nzakas thanks for the documentation link. :)

[jokeyrhyme]

Actually, Shareable Configs is pretty sweet. If you don't think "all" is useful for others, I'd be happy to just close this Issue in favour of Shareable Configs.

[nzakas]

I think this could be useful - just wanted to drill down to the details.

[baer]

@jokeyrhyme - It is going to be very difficult for the good folks at ESLint to maintain sane defaults for all the many variants of JS out there (node, test, browser, coffee, react etc.) and IMO is mostly just a distraction from their main focus. Sharable configs are super awesome and I am ramping up a project using them to try to solve your exact problem. Syncing config across many projects especially if you decompose a la node is a HUGE PAIN!

The fact that the config is sharable enables a more important feature: composable config. I tried to decomposed the rules and made it really easy to both have defaults and customize with only a tiny handful of lines in your config. Anyhow, it's pretty new so any feedback is very appreciated.

https://github.com/baer/eslint-config-defaults
https://www.npmjs.com/package/eslint-config-defaults

[jokeyrhyme]

@baer interesting work there, thanks!

I actually started a project to help me develop configs that don't overlap (e.g. this config is style-only, this config is best-practice-only, etc): https://github.com/jokeyrhyme/eslint-rules-metadata

You might find it useful, although I have a few things I want to do before publishing it to npm. I plan on using it as a way to write tests for shared configs, as well as compare multiple shared configs.

[baer]

@jokeyrhyme - that's awesome! I've been hoping somebody would do that for forever. It's a little sparse on docs but from what I see they are both individually useful and I'd love to work together if there were a good way to. Possibly take eslint-rules-metadata as a dep to help track changes programatically.

This is a bit off topic so lets talk in those two repos. Thanks for the preview :)

[gyandeeps]

@nzakas are we doing this?

[nzakas]

I think we should hold off - let's see if it's requested again.

[barbogast]

I'd like to support the idea of this issue. ESLint has 177 rules right now, and I expect that I'll turn > 90% on with [2]. In this case it's not easy to see which rules are disabled or have a different configuration.

Inheriting from eslint:all would enable me to easily see the disabled rules. I'd just have to disable the rules that I don't like.

Also writing all 177 rules to the config file is a lot of work. And when ESLint updates I have to manually check the changelog or compare the whole list. With eslint:all new rules would be enabled by default and I could disable them if I don't want them.

Concerning plugins: I'm not sure if I would want the rules of plugins to be enabled by eslint:all. I could image that the ratio of wanted vs unwanted rules is be different for a plugin. In this case I would want the rules of the plugin to be disabled by default. Maybe eslint:all could only include eslint rules and <plugin>:all would configure each plugin separately? But if this doesn't work it would be ok for my usecase if eslint:all would enable plugin rules as well.

[mLuby]

I agree with koblaid.

[barbogast]

@nzakas There seems to be interest in this feature so maybe you want to re-open the issue?

[xorcus]

I also agree with Koblaid - I as well like to just relax the rules according to my needs, as opposed to adding all of the restrictions. Please consider reopening and implementing the support for extending "eslint:all". In the end, the feature is optional (no one is forced to extend it), so it should not bother anyone who does not need it. It just increases the flexibility. One can either have everything turned off, and turn on what they need, or the other way around, have everything turned on, and turn off what they don't need.

[platinumazure]

I think this could be useful for core rules.

I'm not sure about plugins-- my thought is that some plugins legitimately cannot have all rules turned on (for example, eslint-plugin-requirejs). I think plugin authors should make a decision about configurations they want to encourage people to extend from, including (if they wish) developing an "all" configuration for their plugin.

[jokeyrhyme]

Let's just go with activating all core rules with eslint:all, and see what the demand is like for activating plugins, later.