search

getify / eslint-plugin-proper-arrows

ESLint rules to ensure proper arrow function definitions
MIT License
305 stars 14 forks source link

@getify/proper-arrows/names should follow func-names schema #22

Closed andreineculau closed 5 years ago

andreineculau commented 5 years ago

and support as-needed and never

afaik async functions would behave the same as sync functions when it comes to inferred names

PS: I don't see why eslint's func-names shouldn't support asyncs, so if a PR gets accepted upstream, it's probably better than having a separate rule doing what func-names does but for async functions

getify commented 5 years ago

You're talking about "async functions", but this plugin focuses on "arrow functions". These are obviously quite separate.

But assuming you meant "arrow function" instead of "async function"...

This rule intentionally diverges from the built-in "names" rule in both behavior and configuration schema, because the concerns of function names are different for arrow functions than for other functions.

For example, the "always" mode wouldn't make any sense for arrow functions, because arrow functions don't get names (syntactically) at all, and that would have the effect of meaning that no arrow-function could be used. Similarly, the "never" mode wouldn't make any sense, because they never get them anyway, so that would be moot.

The "as-needed" mode takes into account the idea of inferred names, so that's why this plugin mimics (most closely) the "as-needed" behavior; that's the only mode of the 3 that makes sense for arrow functions. Moreover, the built-in "as-needed" behavior does not properly account for all inferences, specifically the inferences from a "named-export declaration"; our plugin does it correctly.

PS: I don't see why eslint's func-names shouldn't support asyncs, so if a PR gets accepted upstream, it's probably better than having a separate rule doing what func-names does but for async functions

Again, assuming you meant "arrows" instead of "asyncs" here, yes, I started by thinking this should just be in the core rule. I asked them to do so, and they basically refused (or just didn't care).

Later, as I reflected on things, I realized the behaviors I wanted to do differently with the application of this rule when applied to arrow functions, as detailed above, so I decided it was actually best to keep it separate anyway.

andreineculau commented 5 years ago

once again thanks for the well-written reply! Signed: another "me too!" person

PS: yes, sed /async/arrow/g 😞