'Prefer-Const' Multiple Variable Declaration Option

What rule do you want to change? prefer-const.js

Does this change cause the rule to produce more or fewer warnings? If the rule option is enabled via .eslintrc then instances of multiple variable declarations can be automatically fixed. This should cause fewer errors prompting manual refactorings of these instances.

This comment from the existing source is relevant:

/*
 * If there are multiple variable declarations, like {let a = 1, b = 2}, then
 * do not attempt to fix if one of the declarations should be `const`. It's
 * too hard to know how the developer would want to automatically resolve the issue.
 */

With the new option, developers could choose to use multiple variable declarations in a consistent fashion and have the tool work accordingly.

How will the change be implemented? (New option, new default behavior, etc.)? A new option will be added to the rule allowing the developer to opt in for automatic fixes of multiple variable declarations.

Please provide some example code that this change will affect:

let debug = require('../../')('http')
  , http = require('http');

let a = 1, b = 2;

What does the rule currently do for this code? The rule labels it as an error or warning but fails to automatically fix it.

What will the rule do after it’s changed? If the option is enabled then multiple variable declarations would be automatically fixed and the developer would have to use multiple variable declarations consistently.

[not-an-aardvark]

IIRC, the difficult case is when one of the variables is reassigned and the other variable is not.

let a = 1, b = 2;

b = 3;

prefer-const will report an error for b, but will not autofix it.

I think we should autofix the case where all of the variables types can be replaced with const, if we’re not doing that already.

edit: It seems like we’re not autofixing that case. I’d be fine with autofixing that case by default (without adding an option), and continuing to not autofix the case where some of the variables are reassigned.

[not-an-aardvark]

Thanks for your interest in improving ESLint. Unfortunately, it looks like this issue didn’t get consensus from the team, so I’m closing it. We define consensus as having three 👍s from team members, as well as a team member willing to champion the proposal. This is a high bar by design – we can’t realistically accept and maintain every feature request in the long term, so we only accept feature requests which are useful enough that there is consensus among the team that they’re worth adding.

Since ESLint is pluggable and can load custom rules at runtime, the lack of consensus among the ESLint team doesn’t need to be a blocker for you using this in your project, if you’d find it useful. It just means that you would need to implement the rule yourself, rather than using a bundled rule that is packaged with ESLint.