Rule Change: stop fixing prefer-const

mmkal commented 3 weeks ago

What rule do you want to change?

prefer-const

What change do you want to make?

Implement autofix

How do you think the change should be implemented?

A new option

Example code

let name = 'Alice'
// name = 'Bob'

What does the rule currently do for this code?

Changes it to

const name = 'Alice'
// name = 'Bob'

What will the rule do after it's changed?

Warn, and suggest the fix, but not apply it.

Participation

[X] I am willing to submit a pull request to implement this change.

Additional comments

Reasoning for not wanting it to be auto-fixed:

It makes life harder. I write the above kind of code when debugging, because it's very quick to comment/uncomment the second // name = 'Bob' line, to quickly test things out with a few different values
It's 2024 now. const was introduced so long ago that I suspect it's not usually that helpful to have eslint remind them to use const. It's just a reflex (and some people don't like const at all, they can just disable the rule)

It also is annoying when you set up a mutable variable and accidentally press "Save" before you've got round to mutating it.

The rule is still very useful as a reminder that you need to go back and const-ify anything that was temporary, but I don't think the autofix is. (suggest would be ideal).

I think replacing the fix with suggest unilaterally would be good, but making it configurable would be a fine compromise to me.

Alternatively, if eslint provided a way to downgrade a fix to a suggestion in an end-user's config, that would solve this problem and the dozens of other similar minor gripes I have with other people's rules.

nzakas commented 3 weeks ago

Thanks for the feedback. It sounds like the use case you're describing is when you're applying autofixing on save in your IDE. This is something we don't recommend. ESLint needs completed code to make the best autofix decisions.

prefer-const is actually one of our more popular rules, and when applied to completed code, works as expected.

I'd suggest turning off autofixing in your IDE.

mmkal commented 2 weeks ago

@nzakas thanks. Unfortunately turning off autofixing in-IDE isn't a realistic suggestion, it's a useful part of my/many others' workflows.

I don't agree that ESLint needs completed code to make usefuul autofix decisions, it's extremely useful for as a code-writing aide, fixing things as it goes. There are a couple of minor annoyances like this, but definitely nothing bad enough to warrant the fairly extreme option of giving up on it as an IDE autofixer.

What about the second question - is there a way or could there be a way for an end-user to adjust a rule so it downgrades a fix to a suggestion? Something like:

export default [
  {
    rules: {
      'prefer-const': 'warn:downgradeFixToSuggestion',
    },
  }
]

But maybe with better naming?

eslint / eslint