Change Request: Add option to report on unused/redundant inline configs / configuration comments

[JoshuaKGoldberg]

ESLint version

8.57.0

What problem do you want to solve?

Right now, nothing in ESLint core stops inline configs (configuration comments) from redundantly repeating the same configuration option and/or severity as already exists. This is similar to unused disable directives: they take up space and can be misleading.

• Playground of an inline config setting the same severity as the config file
• Playground of an inline config setting the same options as the config file

What do you think is the correct solution?

The most straightforward change I can think of would be to add a new --report-unused-inline-configs / reportUnusedInlineComments (per the feature's primary naming in #18187) or --report-unused-config-comments / reportUnusedConfigComments (per the common alternate naming).

Participation

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

Additional comments

Inspired by #18218, thanks @inga-lovinde 😄

[nzakas]

This seems like a good idea that is worth exploring in an RFC. Keep in mind, that going forward any new options like this need to work with the language plugins design, which makes things a bit more difficult because we have to take into account how other languages might do inline configs.

[fasttime]

If I'm not misunderstanding the problem, this has been already addressed in #18157. In v9, redundant eslint config comments will produce an error (see repro).

[nzakas]

@fasttime ah good point! @JoshuaKGoldberg do you agree?

[JoshuaKGoldberg]

Ah, I'd missed that, thank you. I think there's only partial overlap though. If I've read it all correctly, #18132 was purely around comments in a single file; this one is both for that (overlap) and comparing comments to the backing config file.

If a rule is configured in a comment the same way as it was in a config file, #18157's changes won't report anything:

// eslint.config.js
export default [
    {
        rules: {
            "prefer-const": "error"
        }
    }
];

// index.js
/* eslint prefer-const: "error" */
export const a = 0;

[nzakas]

Got it, thanks for explaining. In that case, we're back on the RFC track for this.