Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add "arrows" option to "func-name" rule, just like existing "generators" option #11470

getify opened this Issue Mar 3, 2019 · 3 comments


None yet
2 participants
Copy link

getify commented Mar 3, 2019

What rule do you want to change?


Does this change cause the rule to produce more or fewer warnings?

More warnings/errors, but only opt-in (default would be no additional reports).

How will the change be implemented? (New option, new default behavior, etc.)?

New option, similar to "generators", but called "arrows"... with effectively with only one mode: "as-needed" ("always" and "never" do not make sense for arrow functions).

Essentially, the "as-needed" behavior of the "generators" option would be applied to arrow functions as well. IOW, if this "arrows" option is set, flag any arrow function which is NOT going to receive a name inference (such as callbacks, etc).

Just like for "generators", if "arrows" is not provided, fall back to base (so no change to current rule behavior).

To clarify my WHY here, it is my opinion that the anonymity of arrow functions is their worst characteristic, while acknowledging they have some pros. As a compromise, I'd like to be able to allow only arrow functions that will get a name inferred, while disallowing any that can't get any name inference.

Please provide some example code that this change will affect:
What does the rule currently do for this code?
What will the rule do after it's changed?

/*eslint func-names: ["error", { "arrow": "as-needed" }]*/

// OR

/*eslint func-names: ["error", "arrow"]*/

var o = { g: x => x * 2 };   // NO CHANGE: no error (b/c "as-needed")

var p = x => x * 2;     // NO CHANGE: no error (b/c "as-needed") => x * 2);     // CHANGE: error (can't infer a name)

var list = [x => x * 2];   // CHANGE: error (can't infer a name)

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



This comment has been minimized.

Copy link

not-an-aardvark commented Mar 3, 2019

Hi, thanks for the proposal.

Personally, I think requiring names for un-inferrable arrow functions could be sort of annoying in practice when writing code like this:

const foo = bar
    .map(item => item.baz())
    .filter(item => item.quux());

In this case it seems like there isn't really a good name for the individual functions aside from, say, callBaz, which seems like it wouldn't add a lot of documentation or stacktrace value.

I'm not opposed to adding this option is there are other team members in favor of it -- I'm just mentioning why I don't think I would personally use it.

@not-an-aardvark not-an-aardvark added evaluating and removed triage labels Mar 3, 2019


This comment has been minimized.

Copy link

getify commented Mar 4, 2019

I understand that most people are quite happy with all things arrow function, and that my contrarian view on them is non-mainstream, and that's why it seems like a niche sort of rule (though frankly IMO there's several more niche rules than this proposal).

I initially planned to just make my own plugin/rule for this, based off "func-names". But as I worked on it I realized it would be so close to the existing rule that it seems a shame to duplicate forked work instead of merge it in.

Obviously things look a little stranger or contrived with foo/bar/baz types of examples. Here's a more concrete sort of usage I am envisioning:

ids = =>;

// vs

const getId = person =>;
ids =;

I genuinely think the second one reads cleaner, and also fits with a typical FP style where you define a variety of functions (generally through compositions or other higher-order transformations) with good clean semantic names, and then use them.

Anecdotally, whenever I complain (on twitter) about arrow funcs (as callbacks) being anonymous, I get a barrage of responses of people saying they "fix" that by doing exactly what I showed: defining a named const expression. This rule just sorta codifies what seems to be not that uncommon (again, anecdotally).


This comment has been minimized.

Copy link

getify commented Mar 10, 2019

BTW, I would just like to posit that the inclusion of the "prefer-arrow-callback" rule in core is evidence of endorsing/allowing a strong opinion in favor of arrow functions (such that you literally aren't allowed to skip the opportunity to use one!), so I think it would be fair for core to consider supporting an equally opinionated rule (option) to the contrary perspective.

It's undeniable that the "pro" camp for arrow functions is strong and widespread, but I get plenty of "me too!" messages of support on twitter whenever I voice my dissent, too.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.