Fix: no-debugger autofixer produced invalid syntax

[not-an-aardvark]

What is the purpose of this pull request? (put an "X" next to item)

[x] Bug fix

Tell us about your environment

• ESLint Version: master
• Node Version: 8.1.2
• npm Version: 5.0.3

What parser (default, Babel-ESLint, etc.) are you using?

default

Please show your full configuration:

rules:
  no-debugger: error

What did you do? Please include the actual source code causing the issue.

if (foo) debugger

What did you expect to happen?

I expected the code to be valid after running eslint --fix.

What actually happened? Please include the actual, raw output from ESLint.

The code was fixed to if (foo), which is invalid syntax.

What changes did you make? (Give an overview)

This updates the no-debugger autofixer to not remove debugger statements that are in a position where a statement is required (e.g. the direct descendent of an if statement).

Is there anything you'd like reviewers to focus on?

Nothing in particular

[mention-bot]

@not-an-aardvark, thanks for your PR! By analyzing the history of the files in this pull request, we identified @nzakas, @vitorbal and @btmills to be potential reviewers.

[eslintbot]

LGTM

[platinumazure]

LGTM, thanks!

[aladdin-add]

it may be somewhat inconsistent.
can we fix if (foo) debugger to if (foo) ;?

[not-an-aardvark]

In general, we try to make it so that rules don't autofix problems unless they're sure about what the user was trying to do. In this case, I don't think we can be sure.

For example, I think the most likely case where this issue would occur would be if I was trying to isolate a special case in the debugger:

doSomething(foo);
// doAnotherThing isn't working when foo.bar is true, so I'm debugging it there
if (foo.bar) debugger;
doAnotherThing(foo);

But in that case, when I'm done debugging I would actually to remove the if statement entirely:

doSomething(foo);
doAnotherThing(foo);

I don't think it's safe to assume that the user would want an empty if (foo.bar); statement to remain in their code, so it seems best to not fix this case.