⛳ 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.

👉 Contribution guide

[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 = '[email protected]'
// ...
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 :)

[stychu]

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'],
])

Ahh I was looking around for good utlity libs and found es-toolkit. This seems promising but the functionality over lodash seems not on par. I was very sad to find out the most used object util pick doesn't suport nested keys as opposed to loadsh. This simple one prevents me from using es-toolkit for now.

[raon0211]

The usecase for pick will be available from es-toolkit/compat v1.19.0 (which will be released next week). Please refer to our updated docs!

[dayongkr]

To lower the barrier for contribution, I have organized the functions that need implementation into sub-issues.

~~The issues were created using a template for efficiency, so some of the included links may not work. (I am reviewing them one by one)~~ ✅ DONE

Thank you!!

[dayongkr]

For management purposes, existing issues will be marked as duplicates and migrated to the newly created issues. 🙏

[risalfajar]

Could you please add chain, and if it's not possible, add pipe instead? I've explained it in #1187

[jiji-hoon96]

Hi! @raon0211 @dayongkr

As the lodash compatibility work is nearing completion, I'd like to suggest a few core functions that could significantly enhance es-toolkit's value proposition while staying true to your design principles.

Proposed Core Functions

• Object Path Access: get/set/has
• Numeric Range Control: clamp/inRange
• Random Sampling: sample/sampleSize