Incorrect documentation for func-style

[revolter]

Tell us about your environment

• ESLint Version:
• Node Version:
• npm Version:

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

Please show your full configuration:

Configuration

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

What did you expect to happen?

The correct code example for the configuration /*eslint func-style: ["error", "expression"]*/ shouldn't have an arrow function, as they're disallowed by default.

https://eslint.org/docs/rules/func-style#expression

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

/*eslint func-style: ["error", "expression"]*/

var foo = function() {
    // ...
};

var foo = () => {};

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

Maybe.

[platinumazure]

I can't reproduce this: Both examples are lint-free when run in the demo.

It might help to fill in the issue template and share your ESLint version. Also, please let me know if something is wrong with my demo example. Thanks!

[mdjermanovic]

Hi @revolter, thanks for the issue!

I can confirm that the example is actually correct. The "expression" option allows all function expressions and all arrow functions, regardless of the context. It just disallows function declarations.

"allowArrowFunctions": true (default false) allows the use of arrow functions (honoured only when using declaration)

"honoured only when using declaration" applies to the option, and means that this option changes the behavior of this rule only if the main string option is "declaration".

I agree that this sentence can be misinterpreted.

A PR to improve the documentation is welcome!

[platinumazure]

Should we disallow the allowArrowFunctions: true option when the user is using "expression" mode? It's not a great experience to have an option that doesn't do anything in some cases.

[mdjermanovic]

@revolter just to confirm that we understand this bug report:

/*eslint func-style: ["error", "expression"]*/

var foo = () => {};

You think that var foo = () => {}; should be in Examples of incorrect code for this rule with the default "expression" option?

[mdjermanovic]

Should we disallow the allowArrowFunctions: true option when the user is using "expression" mode? It's not a great experience to have an option that doesn't do anything in some cases.

Someone might also expect that ["error", "expression", { "allowArrowFunctions": false }] disallows arrow functions.

Would it be a breaking change to remove a misleading option that doesn't affect the behavior?

[mdjermanovic]

Documentation for the "declaration" option could be also improved.

The option disallows only function expressions/arrow functions used to initialize a variable. It also never disallows arrow functions that use this.

/*eslint func-style: ["error", "declaration", { "allowArrowFunctions": false }]*/

var foo = function () {}; // error

var bar = () => {}; // error

arr.map(function() {}); // ok

arr.map(() => {}); // ok

var baz = () => this.something; // ok

[revolter]

You think that var foo = () => {}; should be in Examples of incorrect code for this rule with the default "expression" option?

Yes.

[mdjermanovic]

Thanks!

The example is correct and the rule is in sync with the example.

That's indeed the intended behavior. If the main string option is set to "expression", arrow functions are allowed.

(even if "allowArrowFunctions" is set to false, because it applies only to "declaration")

I agree that the following can be easily misinterpreted:

"allowArrowFunctions": true (default false) allows the use of arrow functions (honoured only when using declaration)

PR to clarify this option in the documentation is welcome!

[anikethsaha]

Should we disallow the allowArrowFunctions: true option when the user is using "expression" mode? It's not a great experience to have an option that doesn't do anything in some cases.

I think allowArrowFunctions does nothing as arrow function cant be possible for declaration.