Just to clarify the issue, I believe this configuration expects something like:

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

What conflict does this cause? Asking because "conflict" is mentioned in the title.

I suppose it isn’t a conflict; it’s just that i don’t see these as the same as function declarations since they’re under a tdz, and so altho i never want declarations, i do want the export function form.

So, the motivation is to allow hoisting only for exported functions because good practice is to define all exports at the end?

foo(); // this wouldn't be possible here with export const foo = function () {};

export function foo() {};

Unfortunately that does result in hoisting, but in this case I don't care about it, because i don't want to create an extra variable in my named exports.

Unfortunately that does result in hoisting, but in this case I don't care about it, because i don't want to create an extra variable in my named exports.

I'm not sure that I understand the part about an extra variable, an example of code you'd like to avoid with this option would be helpful!

i want to avoid export const = - i don’t want equals signs in my export statements, but i do want to prohibit declarations everywhere else.

Makes sense to me 👍

Unfortunately, it looks like there wasn't enough interest from the team
or community to implement this change. While we wish we'd be able to
accommodate everyone's requests, we do need to prioritize. We've found
that issues failing to reach accepted status after 21 days tend to
never be accepted, and as such, we close those issues.
This doesn't mean the idea isn't interesting or useful, just that it's
not something the team can commit to.

Thanks for contributing to ESLint and we appreciate your understanding.

It'd be great if this could be reopened.

I'll champion this.

How can I help with this?

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

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

Ahhh, that makes sense thanks!

@mdjermanovic any update on consensus from the team? this is still an issue for all the packages I'm writing ESM wrappers for.

@mdjermanovic you championed this initially, do you want to move forward? If so, can you explain the exact change?

@mdjermanovic a friendly ping, waiting for your suggestion to move this issue forward, Thanks.

@mdjermanovic still looking for your input here

I'd still like it to move forward, as the OP :-p the exact change would be one of:

• func-style just ignores inline exported functions
• func-style gets a new option, that when enabled, ignores inline exported functions

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?

An option sounds perfectly fine, thanks.

@ljharb is that in favor of a boolean option or the overrides option?

Either is fine.

@mdjermanovic I think either solution is fine as well, do you have a preference?

I'd prefer overrides:

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

Marked as accepted, PR is welcome.

i see #18444 was filed; i was planning to file one this week since i was traveling last week, but i'm happy @kecrily beat me to it :-)