"prefer-rest-params" vs "fp/no-rest-parameters"

[joshburgess]

I'm a little confused about the intention of using both of these rules, as well as the "Please note that this rule set is meant for use only with ES6 or higher (and the ES7 object rest spread proposal helps a lot)" section of the README.

fp/no-rest-parameters stops you from using rest params altogether: https://github.com/jfmengels/eslint-plugin-fp/blob/master/docs/rules/no-rest-parameters.md

[bodil]

Oops, that's unintentional. I wonder if eslint-plugin-fp introduced that rule in the latest version bump, and I didn't notice.

[joshburgess]

Ah, I see. Do you just not agree with his stance on how it affects currying? Curious about your take on it in relation to FP in JS.

[jfmengels]

I wonder if eslint-plugin-fp introduced that rule in the latest version bump

It was added in the latest version yes. I think that it's "dangerous" to simply extend a config, and would suggest to explicitly define each rule in all plugins, even if eslint-plugin-fp'config is 99% what you wish for. It can add things that you do not deem wanted.

Curious about your take on it in relation to FP in JS.

Same here :)

[bodil]

Fair point about extending configs, with peerDependencies it's harder to enforce explicit versions.

I think I'm leaning towards putting it back in - the scope of this config isn't to turn JS into a curried language, but I'm opposed to variadic arguments on general principle. That's not the only use for the spread operator, though - when used with arrays and (in ES7, maybe) objects, it's a wonderful thing. But none of these rules affect anything but function arguments, right?

[jfmengels]

But none of these rules affect anything but function arguments, right?

Yes. Even though the operator ...xyz looks the same in the following cases, they're considered very different by ESLint.

function fn(...args) {}
callFn(...args)
[...a, b]
{...a, b}

I was thinking of adding a rule to prohibit callFn(...args) (let me know what you think about it), but {...a, b} and [...a, b] are great and I don't mean to forbid them until I hear a good reason for it.

[bodil]

Cool, I think I'll flip that commit over, then - get rid of prefer-rest-params instead.