Allow useEslintrc for cascading overrides

[nickserv]

standard-engine current disables eslint's support for .eslintrc files. I realize this was probably done to simplify configuration and prevent bikeshedding, but I did some research on how .eslintrc files cascade and it seems like it would be useful to prevent configuration duplication with standard-engine.

For example, I'm working on a project using the standard code style and I have some settings I want to apply to all of my test files, but nothing else. With standard (which of course, uses standard-engine), I would either have to set options in package.json (which is global to my project, and covers too many files) or set comments in every test file. I would prefer to use a single .eslintrc file in the root of my test directory to override rules for these settings (I believe eslint itself supports this out of the box). I figure this functionality would be useful for other end users of packages that consume standard-engine.

See Configuration Cascading and Hierarchy.

[Flet]

One option is to use eslint directly with eslint-config-standard. To do this, just make the main .eslintrc this:

{
  "extends": "standard"
}

...and run eslint instead. This will give you the rules of standard with the flexibility of eslint's cascading.

Another person had a similar question (using semistandard which also uses standard-engine. Here are two other options to work around the issue while still using standard:

• its possible to pass -env via the command line and run separate lint commands to treat directories differently
• Its also possible to add commants to the top of each file to turn on/off rules and environments. (example: /* eslint-env mocha */)

Adding a feature to standard-engine to allow overrides is possible, but it would probably not get turned on for standard. One of the core principles of standard is (from standardjs.org):

No decisions to make. No .eslintrc, .jshintrc, or .jscsrc files to manage. It just works.

I hope one of these alternatives helps!

[nickserv]

Thanks for all the info, I actually have been using the eslint-config-standard workaround since creating this issue and it's working nicely. I decided to leave the issue since I was surprised that standard supported the inline eslint comments, but not .eslintrcs.

I totally agree with standard's zero-bikeshedding philosophy in general, though in my opinion .eslintrc would still be useful to many users for setting environments and globals that are directory specific (I'm doing this for my test suite). Besides, you can already bikeshed syntax tweaks by adding eslint comments to a standard project, so I don't think it would be that much of a disadvantage in enforcing the style guide.

[feross]

Thanks for the thoughtful issue. The primary reason that we don't allow .eslintrc files is that it can lead to users accidentally enforcing half standard and half of some other ruleset because they have a stray .eslint file lying around. This led to some really tricky bug reports in the early days of standard.

We allow inline overrides because there always exceptions to rules, and the inline comment acts as documentation of the style violation and should hopefully discourage folks from using it too often. The fact that you have to add the comments to every files is actually a good thing even though it violates DRY (don't repeat yourself), in my opinion.

Since multiple workarounds exist, and I'm -1 on this feature, I'm going to close this issue. But thanks for opening it!

[mightyiam]

While conceptually there would be advantages, like @nickmccurdy describes, I mostly agree with @feross.

And I testify that I had an .eslintrc in my home directory that I've forgotten there. To figure out why my lint run was failing I had to go debugging head first into ESLint. That's where I've spotted the path to that .eslintrc. Even though I appreciate a good debugging session, I'm :-1: on this.

[feross]

Haha, "appreciate a good debugging session" 😆