Fix: fix inconsistently works option in no-extra-parens (fixes #12717)

[yeonjuan]

Prerequisites checklist

• I have read the contributing guidelines.
• The team has reached consensus on the changes proposed in this pull request. If not, I understand that the evaluation process will begin with this pull request and won't be merged until the team has reached consensus.

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

[ ] Documentation update
[x] Bug fix (template) fixes #12717
[ ] New rule (template)
[ ] Changes an existing rule (template)
[ ] Add autofixing to a rule
[ ] Add a CLI option
[ ] Add something to the core
[ ] Other, please explain:

What changes did you make? (Give an overview)

1. Removed !isParenthesisedTwice(node.body) for fixing no-extra-parens options work inconsistently #12717.

   • It will make this rule to ignore checking "double extra parens" if the option (enforceForNewInMemberExpressions : false) is specified.

2. Added some tests for checks whether they ignore "double extra parens" when the option is specified.

   • Other options which not added test in this PR already have test cases ensuring it.
   • returnAssign, nestedBinaryExpressions, enforceForSequenceExpressions, enforceForNewInMemberExpressions.

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

In my understanding, an arrow function's block statement body can't be parenthesized(), because it will change the body's type BlockStatement to ObjectExpression.

var a = () => {  }; // BlockStatement
var a = () => ({ }); // ObjectExpression

And there is a checking about "double extra parens" when body type is not a BlockStatement.

if (node.body.type !== "BlockStatement") {
   // ...
    if (hasExcessParensWithPrecedence()) { 
 
   }
   // ...

So, I think !isParenthesisedTwice(node.body) can be removed without another effect.

[kaicataldo]

Thanks for working on this! Appreciate the additional tests for existing behavior 👍

[kaicataldo]

LGTM, thanks!

[mdjermanovic]

It's interesting that the non-optional exception for IIFE doesn't allow parens around IIFE if the function expression has parens:

/* eslint no-extra-parens: ["error", "all"] */

((function foo() {return 1;})()) // error

This is actually the example from the documentation where it says that the rule always ignores extra parentheses around the immediately-invoked function expressions.

But it seems to be intentional: #3667 (comment)

So I'm not sure should we change this now, or leave it as is (but fix the example in the documentation).

The rule also doesn't allow double parens around IIFE even if the function expression doesn't have parens.

[mdjermanovic]

LGTM, thanks!

It seems that only the built-in IIFE exception doesn't allow multiple parens, but it's better to leave that as is.

The wrong ((function foo() {return 1;})()) example for IIFE can be fixed in PR for #12870.

[mdjermanovic]

This was definitely intentional (#8439 comment). Unfortunately, other options don't work like this, so it's better to align.