no-unused-vars should report all unused function parameters that match the configured setting
See original GitHub issueI’m creating this as an attempt to refocus the discussion in #9750 into a specific proposal I have (although I think @g-plane would agree with me as well).
What rule do you want to change?
no-unused-vars
Does this change cause the rule to produce more or fewer warnings?
More
How will the change be implemented? (New option, new default behavior, etc.)?
New default behavior for args: "after-used"
option: Report all unused parameters which occur after the last used parameter. This would be done as 1 lint message per unused parameter.
Note that this is not really a breaking change:
- When the user has no unused parameters after the last used parameter, the rule will continue not to report any violations.
- When the user has at least one unused parameter after this last used parameter, we currently report 1 parameter at a time.
- When the user removes the unused parameter, we report the next unused parameter. Net effect for the user is to (eventually) see lint messages for all unused parameters after the last used parameter.
- This proposal is just to report them all at once.
Please provide some example code that this change will affect:
/* eslint no-unused-vars: ["error", { "args": "after-used" }] */
function (a, b, c, d, e) {
c();
}
For more examples, see demo.
What does the rule currently do for this code?
For code block above: Reports that e
is unused.
For demo: See lint results.
What will the rule do after it’s changed?
For code block above: Reports that d
, and e
are all unused.
a
,b
,d
, ande
are unused.- But
d
ande
are after the last used parameter (c
). - So report both
d
ande
.
For demo: See comments in code.
Note: args: "all"
works correctly and needs no changes.
I’ll champion.
If there’s a strong reason for reporting only one of the unused arguments (and no, “the docs say so” doesn’t count, that’s circular reasoning), that can be expressed here as part of a 👎 to this proposal.
Issue Analytics
- State:
- Created 6 years ago
- Reactions:6
- Comments:17 (17 by maintainers)
Top GitHub Comments
Yes, I think that’s correct based on looking at the old versions of the code.
I think this might be coming from an ambiguity in our definition. To be clear, this increases the number of warnings on some lint runs, but it only does this in cases where at least one warning would have been reported anyway. In other words, there are no cases in which a warning would start to be reported where no warnings were reported before.
There was a similar case in https://github.com/eslint/eslint/pull/7095#issuecomment-246195723 when we updated
quote-props
to report individual errors for each property, rather than reporting the object as a whole. We ended up calling that a semver-minor change.@nzakas I’ve added “breaking” label for now, but I disagree that this is a breaking change. I’ve explained why in the initial post, but here it is again for convenience:
The overall number of errors is actually unchanged; it’s just reported over one linting runs. And-- this is the important part-- there is no situation where 0 issues are currently reported, and >0 issues are reported under this proposal.
Using this example as a reference:
In my example, we instead go from 1 issue reported in 2 lint runs (
e
reported, thend
whene
is removed), to 2 issues reported (d
ande
in the same run).In this example:
No report is generated right now, and no report will be generated with this proposal.
So since there are no new linting errors introduced where previously there were no linting errors, I don’t think this is a breaking change.