Differentiate between named functions and getter/setter functions.

This is not a new rule, but an extension of the core space-before-function-paren rule. I am filing this as part of my research efforts to answer a stackoverflow question I made today.

When does this rule warn? Please describe and show example code:

This rule adds a third parameter to space-before-function-paren to allow for custom spacing for getter/setter functions.

"space-before-function-paren": [2, {
    "anonymous": "always",
    "named": "always",
    "getterSetter": "never"
}]

This allows for code like this to stop throwing errors when using "always" for "named" functions.

var myObject = {
    get myProperty() { return 'foo'; }
};

This aligns getter definitions with what mdn recommends in their example.

Is this rule preventing an error or is it stylistic?

Stylistic.

Why is this rule a candidate for inclusion instead of creating a custom rule?

This rule seeks to extend an existing ruleset. It makes sense to include it as an option in an already well-known ruleset, instead of isolating it in its own rule.

Are you willing to create the rule yourself?

If you’re ok with me altering a core rule. I see that get and set are already tracked under parent.kind when evaluating named functions explicitly. This means that the interpretation of how getter and setters are defined will need to be decoupled from named functions. If I’m able to make a clean break at the definition of what a named function is, it should be as simple as wrapping an if statement around that area of the code.

If I’m unable to make a breaking change that way, I may still be able to support some kind of a legacy definition of named functions as including getters/setters, and then over-ride that definition to include a finer grained definition if and only if they include the third option explicitly. However, just writing all that out made me cringe. I imagine it would look and feel much worse when implemented. Exposing variable definitions of core concepts of the ESLint parser sounds like a terrible precedent to set.

[kaicataldo]

Closing this because we haven’t made any progress in months. Thanks for contributing!

[nzakas]

If this is separating out accessors from named functions, it’s a breaking change, so we need to be very certain that this is what we want.

Also, if we do want this, should we also have an option for concise methods?