eslint: `func-style` "expression" conflicts with ESM named exports

What rule do you want to change? func-style

Does this change cause the rule to produce more or fewer warnings? Fewer or more, depending on how the option is configured.

How will the change be implemented? (New option, new default behavior, etc.)? A new namedExports option, which can be set to “expression” or “declaration” or “ignore”.

Please provide some example code that this change will affect:

/* eslint func-style: [2, "expression"] */
export function foo() {}

What does the rule currently do for this code? warns

What will the rule do after it’s changed? /* eslint func-style: [2, "expression", { "namedExports": "declaration"] */ will cause no warning to be issued.

Are you willing to submit a pull request to implement this change? Yes.

About this issue

Original URL
State: open
Created 4 years ago
Reactions: 4
Comments: 23 (20 by maintainers)

Most upvoted comments

I don’t think this rule should ignore named exports by default.

We could add a boolean option to ignore named exports:

"func-style": [2, "expression", { "ignoreNamedExports": true }] // `false` by default

or an option to override base settings for named exports or ignore them:

"func-style": [2, "expression", {
    "overrides": { 
        "namedExports": "declaration" // allowed values are: "expression", "declaration`, "ignore"
    }
}]

The latter is similar to the original proposal, I only added "overrides" because options that override base settings for certain cases are typically under "overrides" in core rules.

Thoughts?

mdjermanovic on Apr 4, 2024

@krainboltgreene this enhancement doesn’t have consensus from the team yet.

If and when this issue gets accepted, a PR will be welcome 😃

mdjermanovic on May 14, 2020

I’ll champion this.

mdjermanovic on Feb 26, 2020