no-extra-parens conflicts with wrap-iife

Tell us about your environment

• ESLint Version: 7.0.0-alpha.0
• Node Version: v12.14.0
• npm Version: v6.13.4

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

default

Please show your full configuration:

Configuration

module.exports = {
    parserOptions: {
        ecmaVersion: 2015
    },
};

What did you do? Please include the actual source code causing the issue, as well as the command that you used to run ESLint.

/* eslint wrap-iife: ["error", "inside", { functionPrototypeMethods: true }] */
/* eslint no-extra-parens: ["error"] */

var x = function(){}.call(); // wrap-iife error

var x = (function(){}).call(); // no-extra-parens error

Online Demo Link (demo is v6.8.0, but it’s same)

eslint index.js --fix

What did you expect to happen?

These are two same lines, except for the parens around the function expression.

wrap-iife requires these parens, while no-extra-parens disallows them.

I’m not sure what should be expected default behavior for no-extra-parens:

This rule always ignores extra parentheses around the following:

immediately-invoked function expressions (also known as IIFEs) such as var x = (function () {})(); and ((function foo() {return 1;})()) to avoid conflicts with the wrap-iife rule

This isn’t quite an IIFE, but it is a conflict with wrap-iife.

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

Autofix worked 10 times, so the code at the end remained unchanged, with the following errors:

  4:9  error  Wrap an immediate function invocation in parentheses  wrap-iife
  6:9  error  Unnecessary parentheses around expression             no-extra-parens

If it was set to run an odd number of times, it would basically flip those two lines.

Are you willing to submit a pull request to fix this bug?

Yes. I’m not sure should this be default or an option.

[mdjermanovic]

I’m working on this.

[mdjermanovic]

Since wrap-iife doesn’t warn on this by default, I don’t think this should be the default behavior of no-extra-parens. Thoughts on adding a corresponding option to no-extra-parens (enforceForFunctionPrototypeMethods, maybe?) that defaults to false?

Agreed! It seems better to add an option.

Only, I think it should be true by default, like all other options in this rule. true would also retain the current default behavior.