-
-
Notifications
You must be signed in to change notification settings - Fork 4.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Change Request: Add option to report on unused/redundant inline configs / configuration comments #18230
Comments
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 ah good point! @JoshuaKGoldberg do you agree? |
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; |
Got it, thanks for explaining. In that case, we're back on the RFC track for this. |
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. |
I think this is still relevant |
@inga-lovinde I agree, it's still relevant, but we need an RFC to proceed. |
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.
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
Additional comments
Inspired by #18218, thanks @inga-lovinde 😄
The text was updated successfully, but these errors were encountered: