RE: generator-star-spacing: work better together with space-before-function-paren #6195

[EthanRutherford]

I'd like to drag this one back up, because I feel it should still be addressed
(original issue #6195)

To summarize, the issue is that with the rules as below:

"space-before-function-paren": ["error", "never"],
"generator-star-spacing": ["error", {"before": false, "after": true}]

an anonymous generator function can never satisfy both rules

function*()   // fails generator-star-spacing after: true
function* ()  // fails space-before-function-paren: never

This is still an issue that needs a resolution.
A decent half-fix would be to allow an unset "before" or "after" in generator-star-spacing to behave as if the rule is off for that half, only enforcing the rule for the values which are explicitly set.

"generator-star-spacing": ["error", {"before": false}]

A better more complete fix would be, as discussed in the previous issue, add configurability based on the function type (named, anonymous, method), in addition.

"generator-star-spacing": ["error", {
    "named": {"before": false, "after": true},
    "anonymous": {"before": false, "after": false},
    "method": {"after": false}
}]

function* gen() {}
let g = function*() {}
let m1 = {*method() {}}
let m2 = { *method() {} }

[ilyavolodin]

Thanks for the issue. I think half-fix is probably not great, due to the fact that we need some sane defaults. But full configuration proposal sounds reasonable to me.

[EthanRutherford]

Could we get some eyes on this issue? I feel like the solution I've implemented is an effective fix for the issue, and is backward compatible to boot. It should be just a matter of getting it approved.
If there's something objectionable to the solution, I'd be happy to take feedback on it, so that I can address said objections and create a better solution.

[not-an-aardvark]

cc @eslint/eslint-team: Any thoughts on this proposal? It looks like it just needs a champion to move forward.

[not-an-aardvark]

By the way, one thing I want to bring up is that the async iteration proposal will introduce a new case here for async generator methods:

var obj = {
    async *x() {}
};

We don't need to support that proposal right now, but it's likely that that syntax will need to be supported at some point, so we should try to make this proposal forwards-compatible so that we can extend it in the future if necessary. (It seems like that might already be the case -- for example, we could add an asyncMethod property later on -- but I just wanted to bring it up as something to consider.)

[kaicataldo]

I'll champion this.