Closed davidwkeith closed 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.
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.)
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?
Closing for now.
The following will report a params count error:
While the following won't
This might be intentional, as it seems weird to use the pattern in an anonymous function, but the lint error should be more exact.