Move off `eslint-plugin-fp`

[lishaduck]

Hello there! Sorry to file so many issues, I just haven't had time to/forgot to before now :)

eslint-plugin-fp is a handy plugin sheriff uses that was made by the the wonderful @jfmengels, who wisely chose to move on from JS to the fantastic land of Elm, but unfortunately in doing so left his JS repos unmaintained. 🙃 However, we in Elm land (read: me) often still need to write JS, but we'd like to do so in a functional style reminiscent of Elm. Therefore, I use sheriff as a handy helper to enforce a modern, functional style. I recently discovered eslint-plugin-functional, which is a modern, maintained (not drop-in) replacement for eslint-plugin-fp. Would be interested in a PR migrating us?

[AndreaPontrandolfo]

I know about eslint-plugin-functional. Some years ago i was comparing eslint-plugin-fp and eslint-plugin-functional. In the end i opted for eslint-plugin-fp because it seemed more straightfoward. I had another look yesterday at eslint-plugin-functional. It got recently updated and surely improved from the last time i looked at it. But i still think it's fundamentally incompatible with Sheriff. Taken from the docs:

Sheriff don’t offer a “recommended” or “strict” config. This config is a predefined set of rules meant to act as guidelines for a functional-light programming style.

Sheriff is meant to encourage light-functional-programming practices. Every single eslint-plugin-functional rule is too fp-hardcore for Sheriff. And YET, if anybody want to go for the fp-hardcore path, they CAN. Sheriff doesn't impede anybody from installing and using eslint-plugin-functional. Anybody can use it alongside Sheriff without issues, if they wish so. But it's just not a right default for Sheriff, it doesn't belong here. I think the only mildly interesting rule that i saw in eslint-plugin-functional is prefer-tacit. Actually, this got me thinking that we can probably even remove eslint-plugin-fp. We are currently using eslint-plugin-fp just for 3 basic rules that could easily be re-implemented with no-restricted-syntax. And fp/no-arguments is already useless i think, because we are already employing prefer-rest-params.

What do you think?

[AndreaPontrandolfo]

Also, as a side-note, since you are interested in fp-libraries, i'm currently working on eslint-plugin-remeda. When that will be ready (actually it's already working, but i'm thinking of adding some extras and polishing it a bit before considering it production ready. Contributions are welcome ofc), i'll add it to Sheriff as an opt-in.

[lishaduck]

Ok then. I assumed we we using the recommended config, and was thinking that no-classes, etc could be switched over. However, I agree that no-restricted-syntax is probably better, as it's lighter. I mainly just want to reduce the amount of lodash, etc in my dependencies.

I noticed that. Remeda looks nice, but I'd also prefer to keep the number of copies of those sorts of libraries in my node_modules down. I've also been slowly migrating code to Effect-TS which looks like the two might conflict a bit there.

[AndreaPontrandolfo]

@lishaduck yeah, definitely you should only use Effect-TS or Remeda, not both at the same time. Effect-TS kinda scares me, it seems very heavy. How are you liking it so far?

[lishaduck]

@lishaduck yeah, definitely you should only use Effect-TS or Remeda, not both at the same time. Effect-TS kinda scares me, it seems very heavy. How are you liking it so far?

It's nice. I like it. It's certainly not something I want to bundle, so I kept in in scripts, and I want to start replacing zod with it. My main thing is that there isn't a platform-deno yet, which is preventing me from doing to much. It's not bad to work around, I just don't want to write a bunch of code that'll need refactoring again soon.