Update: add fixer for no-extra-parens (fixes #6944)

[not-an-aardvark]

What issue does this pull request address?
#6944

What changes did you make? (Give an overview)

This adds an autofixer to no-extra-parens, allowing it to be fixed automatically with the --fix option.

Is there anything you'd like reviewers to focus on?
#6944 has not been marked as accepted yet, so this PR shouldn't be merged until it is.

It's probably worth double-checking this logic to make sure there are no other special cases that need to be addressed.

[mention-bot]

@not-an-aardvark, thanks for your PR! By analyzing the annotation information on this pull request, we identified @michaelficarra, @nzakas and @mysticatea to be potential reviewers

[eslintbot]

LGTM

[michaelficarra]

This is only necessary if the parenthesised expression starts with an IdentifierPart. You can use esutils.isIdentifierPart for this test.

edit: An example test case:

typeof([]);

should be corrected to

typeof[];

[not-an-aardvark]

That fix works, but I wonder if it could just always output a space after keywords, and then let the keyword-spacing rule clean up if the spacing is wrong.

On the other hand, I suppose it's better to modify the code as little as possible.

[michaelficarra]

I'm okay with either way.

[not-an-aardvark]

Fixed; it now only adds a space if it's necessary to prevent an error, so typeof([]) will get fixed to typeof[].

[michaelficarra]

You also have to watch out for +(+a), -(-a), and (0).a. They must be corrected to + +a, - -a, and 0..a (or 0 .a) respectively, not ++a, --a, or 0.a.

[not-an-aardvark]

Good thinking with +(+a) and -(-a); I'll fix those and add tests for them. However, (0).a is currently not identified as an error by this rule, so it doesn't need to be addressed.

[michaelficarra]

Hmm, that must be a bug then.

edit: Oh, I remember. We made a special exception for this case.

[not-an-aardvark]

Based on #6864 it seems to be intended behavior, but it does seem a bit inconsistent to me.

[not-an-aardvark]

By the way, couldn't +(+foo) (and maybe -(-foo)) simply be corrected to +foo?

(edit: changed 5 to foo)

[michaelficarra]

For 5, sure, but in general, no. It's observable.

edit: Sorry, I was thinking of just reducing it to 5. Reducing to +5 is probably safe, yeah.

[eslintbot]

LGTM

[not-an-aardvark]

I updated it to add a space rather than getting rid of the extra +, since we're not trying to minify peoples' code and they might be surprised if an operator disappears.

[ilyavolodin]

LGTM