Change Request: report unnecessary config overrides

[ljharb]

ESLint version

v8.5.0

What problem do you want to solve?

1. I extend a shared config in the root / I set a rule in the root
2. I override a rule from the shared config, or add a rule not present in the shared config / I override a rule set by the root in a nested config or override
3. Later, the shared config changes such that the local rule configuration is a unused, ie, prevents no warnings / Later, I change config in the root such that the nested config or override is unused, ie, prevents no warnings

The problem is that it's really difficult to figure out when the third step applies.

What do you think is the correct solution?

Like the reportUnusedDisableDirectives config option, I would like a config option that reports unnecessary configuration - in other words, any configuration that exists that matches the existing inferred configuration.

Participation

• I am willing to submit a pull request for this change.

Additional comments

I'd need many pointers to submit a PR for this, but I'm happy to help where I can.

(filed based on #15466 (comment))

[nzakas]

Interesting idea. I’m thinking through how we could do this in the new config system and I think it could be pretty easy to detect (Famous last words.) but I’m not sure what kind of behavior would make sense. Also, would this apply to rule configuration directive inside a source file?

What is the behavior you’d expect if a dupe was found? What would happen if one shared config you extend has the same rule options as another shared config you extend?

Note this is different than reporting disable directives because those are in the source file and so they can look like any other linting error.

[ljharb]

I’d expect anything that wasn’t the first definition for a rule, that matched a previously established one, to be warned on - inline or not.

i would not expect it to warn on anything from a shared config itself - only on things within the current repo. In other words, if after extending two shared config, i then defined something unnecessary, I’d expect my definition to be reported.

[nzakas]

Gotcha. And how would you expect it to be reported in the output?

[ljharb]

The same way that unused disable directives are - but i suppose the interesting question is “under what filename”? It seems like it’d show up under the file it was in, whether it was inline or a config file.

[nzakas]

Yes, that’s the problem, there’s not always going to be a filename to show (if you’re only using shared configs), and if there is a file, we don’t have any location information for where in the file the rule config is being set.

So, I don’t think we can treat this like a linting error.

[ljharb]

There would always be a filename tho - it wouldn’t report the shared config, only in-project config files

[nzakas]

Ah sorry, I missed that earlier. In the new config system, it’s not easy to tell the difference between shared configs and local configs, as it’s just an array of objects. We can detect dupes, but I don’t think we can get exactly what you want. The only real option is to just throw an error for any dupes (not treated like a linting error).

[ljharb]

That seems like a flaw in the new config system that still has time to be corrected?

[nzakas]

It's not a flaw, it's an intentional design decision. We no longer want ESLint to have to load modules. Instead, we want you to use import, require, etc. to pull in what you want and place it into the config array. That's how we will escape the shared config loading hell we can get stuck in right now.

I think the best course forward right now is just to wait until we have the new config system ready for testing and see what would make sense.

[github-actions]

Oops! It looks like we lost track of this issue. What do we want to do here? This issue will auto-close in 7 days without an update.

[ljharb]

The unfortunate aspect of that design decision is that it will no longer be possible to have a static configuration.