⛳ Goal: Almost feature parity with lodash

[raon0211]

For easy migration from lodash to es-toolkit, our goal is to achieve almost complete feature parity with lodash.

For details, please refer to our compatibility documentation.

We intend to migrate most of the functions that lodash offers, with the following exceptions:

• Functions that have specialized implementations for specific types of arrays, like sortedUniq.
  • Such functions fall outside the scope of es-toolkit.

If you encounter any lodash features that could complicate migration to es-toolkit, please inform us via comments on the issue.

[dcastil]

Was just checking whether we can replace lodash with es-toolkit and noticed that we're using the lodash pick function with deep keys, like

const pickedObject = pick(object, [
    'firstLevel.secondLevel.thirdLevel',
    'firstLevel.anotherKey.thirdLevel',
    'firstLevel.anotherKey.anotherKey',
])

Would it make sense for es-toolkit to provide a similar function? Maybe an API like this could work with type safety on the keys?

const pickedObject = pickDeep(object, [
    ['firstLevel', 'secondLevel', 'thirdLevel'],
    ['firstLevel', 'anotherKey', 'thirdLevel'],
    ['firstLevel', 'anotherKey', 'anotherKey'],
])

[arty-name]

I’ve noticed another major lodash feature seemingly not being supported. I very much enjoy how concise lodash makes the following code:

const email = 'test@example.com'
// ...
const user = find(users, { email })
// as opposed to
const user2 = find(users, user => user.email === email)

[KeKs0r]

Also did a short scan of my codebase and would love to replace lodash, mainly for the bad types of it.
The following seem to be not yet covered:

• mapValues & mapKeys
• find with object as query (as described by @arty-name
• map - which I use to map over an object and return an array. I dont think doing these 2 things in 2 steps would be too bad though
• max and min - could easily be done by maxBy and minBy. Maybe worth considering having the identity function as default iteree
• set and has to check deal with deeply nested properties

Would love to hear your opinions. I don't think those necessarily need to be implemented, but I think extending and making the "not gonna implement" list as well, will be beneficial.

[damianobarbati]

It would be nice to have this pkg be a drop-in replacement for lodash and lodash-es. For now, I can't migrate because isEqual cloneDeep and isEmpty are missing.

[tom2drum]

Just wondering if you could add support for defaultsDeep as well?

[raon0211]

Hello!

We're striving for perfect compatibility with lodash through es-toolkit/compat. We're actively adding missing functions to our library and importing unit test cases from lodash to ensure 100% accuracy.

If you add comments to this issue, we will prioritize adding support for your case.

For more details, please visit our compatibility page.

[krasnovmv]

Hello

I have attempted to migrate a large project to es-toolkit, but I got tired of manually checking whether a function has been migrated or not.
Do you have any plans to create a codemod for incremental migration from lodash/lodash-es to es-toolkit? I just want to run the command after the next update and replace all the imports of the implemented functions

[raon0211]

It should be fine to just replace lodash or lodash-es to es-toolkit/compat when we achieve full compatibility with lodash. While we're on the way, and many frequently used functions are migrated, we expect the migration to be complete by the end of this year.

[danieldelcore]

I'm iterating on a pretty naive codemod here in case it helps:

https://www.hypermod.io//sandbox/cm036l7jf0001l20cf89mvmev

I'm going to go in and add proper coverage as per the support table here later today :)