[Feature Request] Remeda ESLint Plugin about remeda

[cjquines]

i think the eslint plugin is a good idea; is that the only feature request from this issue? if so, let's rename this issue and use it to track this?

[eranhirsch]

Hello, and thanks for the kind words. I'll jump right in:

• Being compared to lodash is both a blessing and a curse. One thing that constantly creates strong opinions is how we name stuff: If we choose to name everything like Lodash, we lose out on making the function names better, when possible, e.g., Lodash's toPairs and fromPairs when ECMAScript has chosen entries instead, or Lodash's choice of abbreviating function names instead of calling them by their full name (cond vs conditionally). Looking at the future and wanting to be the next lodash and not just a reimplementation of Lodash we need to make a choice here.
• As for eslint, I don't know what the lodash lint plugin does (but planning on checking it out!), but it's probably overkill for us to build a Remeda plugin as other eslint plugins already do a great job (we can highly recommend unicorn as a supplement to the typescript plugin, and there is the functional programming one, although it's extremely FP 😉).
• A note about migration: I think that once you remove lodash from your project your team would more likely adopt the replacement (they don't have a choice), so it's more about getting lodash out. For that, I've considered a "codemod" tool to help people convert existing projects from lodash to remeda, but those sorts of tools are not trivial to get right (but we'd be happy to get help building them!).
• We don't benchmark remeda against other utilities but never get any feedback about performance issues. On the contrary, our lazy pipes are probably a perf benefit users get "for free" without needing to think about it, and they also help greatly with memory problems which aren't reflected in these sort of benchmark tests. We've introduced a lot of changes over the years and the benchmark from ts-belt doesn't mention what version it was tested against, so it's hard to know if they are reflected in those benchmarks. In v2 we continue to improve our runtime implementations, and we have plans to introduce more "iterator"-style improvements to make almost all functions run lazily where possible. TL;DR - this is not top of mind, but it's also not obviously a problem.
• I'm totally for the Discussions tab, I don't know though how to structure the project to facilitate it, and the current rate of traffic is such that we can handle it with only issues and PRs. We will consider organizing the project with discussions (and maybe projects) in the near future if we find it useful.

[AndreaPontrandolfo]

The point is not the Lodash > Remeda migration. That's the easy part, because most utils overlap, even by names.
The point is minimum feature parity between Lodash and Remeda.
The Lodash ESLint plugin is fundamental for me, because without that, overtime, my team-mates would turn our codebase in a mess. This is an important code-quality consideration that i'm sure many lead-devs would make.
Without such a feature i cannot see myself comparing Lodash and Remeda on fair grounds. The utils themselves are just a part of the story, the ecosystem is equally important too.

[AndreaPontrandolfo]

Thank you for clarifying the perf concerns, it totally makes sense.

About ESLint, let me clarify what i wanted to express.
Unicorn and ts-eslint have nothing to do with it.
The main benefit of eslint-plugin-lodash is the following.
If any of my team-mates write code like this:
const t = x === undefined || x === null;
ESLint will auto-fix it (in-editor) with:
const t = isNil(x);
Another example:
array.length > 0
becomes
!isEmpty(array)
It's very powerful, ESLint will warn your developers whenever they are doing something with Vanilla JS where is could be better expressed with Remeda utils, and then it actually autofix it in-editor!
Then, with time, developers of the team will start to reach for Remeda utils themselves.

A note about migration: I think that once you remove lodash from your project your team would more likely adopt the replacement (they don't have a choice), so it's more about getting lodash out. For that, I've considered a "codemod" tool to help people convert existing projects from lodash to remeda, but those sorts of tools are not trivial to get right (but we'd be happy to get help building them!).

See? Here you would just be reimplementing the ESLint CLI functionality: eslint --fix. Link.
Once the plugin is developed, adopters of Remeda could migrate just by running eslint --fix from their command-line.

[AndreaPontrandolfo]

Even Ramda has one.
Not a coincidence. Lodash and Ramda are the 2 most popular JS util libs out there.

[eranhirsch]

Your examples are from vanilla JS to lodash/ramda, not from one library to the other. If your project is already using Lodash, the vanilla -> Remeda is not the main hurdle to adoption, the lint rule wouldn't help in those cases.

[AndreaPontrandolfo]

Yes, fine by me 👍