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.

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.

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

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.

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.

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?

Yes, fine by me 👍

I'll start working on this today.
Unfortunately, Remeda repository is not a monorepo, so i cannot directly make a PR here.
I'll have to start a separate repository.
If there are no plans to make the Remeda repository a monorepo, eventually eslint-plugin-remeda could be made part of the Remeda Github Organization.
Let me know what you think.

I started working on it in here https://github.com/AndreaPontrandolfo/eslint-plugin-remeda.
It's still a WIP, but let me know if anyone would like to help.

Hey guys, made some decent progress over at eslint-plugin-remeda.
I used the (now unmaintained) eslint-plugin-lodash as a starting point and i'm iterating from there.

The progress i made so far:

• added some good first-issues. Mainly stuff about converting the codebase to modern standards that are easier to work with.
• almost finished to completely rewrite the README.
• made some rules usable (just 5 at this time, but it's a start). The plugin is still not published on NPM, but the tests are passing so i'm relying on them, for now.

If if there is any specific recommendation or guideline let me know.
Also, again, any help would be appreciated. Also suggestions.

I'll keep going and keep you updated on the status of the project.

@AndreaPontrandolfo that's cool! my main question is, if you're basing this off of eslint-plugin-lodash, do you know how the license works for that?

it looks to be MIT.
It doesn't really means much anyway, when all the rewrites will be done, 90% of the code will be different/original.
It's more a starting point to get off the ground quickly.
Also, 2 of those rules i wrote myself. And most of the rest i already deleted because they are incompatible with Remeda.

Hey guys, another update!

I finally published the V1 of the package on NPM! eslint-plugin-remeda
All the tests are passing. I also tested it on the ground in a random typescript repo and every rule seems to be working as expected, except prefer-nullish-coalescing , not sure why it's not working, i'll have a closer look at it.
There are currently 14 active rules, but i plan to add more and refine the current ones with some small adjustments and make all of them autofixable (most of the already are, but 'll make sure).
Also i'll be restructing the repo with Typescript and ESM --> AndreaPontrandolfo/eslint-plugin-remeda#1

Let me know if you have any feedback or if you have any interest in collaborating!