Remove fixer from no-debugger rule

What rule do you want to change? no-debugger

Does this change cause the rule to produce more or fewer warnings?

Fixer for this rule forces me to put eslint-disable-next-line comment before debugger statement rending this rule useless.

With fixer for no-debugger my IDE’s (VS Code and vim) fix-on-save feature removes debugger statement the moment I save the file. I have to use

// eslint-disable-next-line
debugger

construction and I already have debugger statement slipped into production code at least twice.

How will the change be implemented? (New option, new default behavior, etc.)?

Please remove the fixer completely or make it optional. I’ve read the comment https://github.com/eslint/eslint/pull/8660#issuecomment-315806299 and I still think that for no-debugger rule fixer is kind of useless. You’ll never have more that one or two accidentally forgotten statements to force IDE creators to implement such mechanism.

[not-an-aardvark]

This idea was also discussed in https://github.com/eslint/eslint/issues/7873 (and has come up in a few other places, e.g. https://github.com/eslint/eslint/issues/7714). We’ve generally been following the policy that autofixers should never change the behavior of user code. I’m not convinced we could ever be sure enough of the user’s intentions that it would be a good idea to change the behavior of their code without user input.

[michaelficarra]

There seems to be two conflicting goals people have when using eslint’s auto-fixing.

1. Those running it on save want only stylistic rules fixed. In my opinion, this is the domain of prettier.
2. Those using it so that they don’t have to manually fix the things that they’ve told eslint are undesirable.

For the first group, changing anything that we could fix automatically but which changes the structure/behaviour of the program is unwanted. For the second group, not changing something that we could fix automatically adds burden on them.

It looks to me like the way to resolve this is to have auto-fixing run in one of two modes: fix only stylistic things, and fix anything that we possibly can.