getify / eslint-plugin-proper-arrows

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

False positive on object destructuring in arrow function parameters #24

Closed davidwkeith closed 4 years ago

davidwkeith commented 4 years ago

The following will report a params count error:

({foo, bar, baz, bat, bongo }) => {/* a function that handles all those 'named' parameters */}

While the following won't

function namedParams({foo, bar, baz, bat, bongo }) {/* a function that handles all those 'named' parameters */}

This might be intentional, as it seems weird to use the pattern in an anonymous function, but the lint error should be more exact.

getify commented 4 years ago

This plugin is called "proper-arrows" and thus only applies to arrow functions, not all general functions. There are many built-in ESLint rules which apply rules to functions generally, but I wanted this plugin to apply rules specifically for arrow functions.

In this specific case, this "max-params" built-in ESLint rule can be used: https://eslint.org/docs/rules/max-params#enforce-a-maximum-number-of-parameters-in-function-definitions-max-params

This plugin's params-count rule specifically is intended to be used when you want to apply a limit ONLY to arrow functions, with a different (or no) limit applicable for non-arrow functions. If you just want the same params-count applied for all functions, disable this plugin rule and use the built-in "max-params" rule instead.

davidwkeith commented 4 years ago

Makes sense, but technically there is only one argument, maybe breaking both of these rules into two parts, arguments and pseudo named arguments. Named arguments are easier to reason about and should be encouraged for when a longer method signature is required. (though really shouldn't be an arrow function then)

I will play around with the main ESLint rule and see if I can configure it to do what I want. (fewer unnamed parameters, and a reasonable, but larger amount of "named" parameters.)

getify commented 4 years ago

All parameters are named. Some parameters are named in the form function foo(x,y,z) and some are named in the form function foo({ x, y, z }), but in both cases they're named. AFAIK, the ESLint rule treats both these forms identically with respect to counting and limiting parameters, and my plugin does the same.

I'm not seeing why you would want to allow a different count depending on the form, here?

getify commented 4 years ago

Closing for now.