Why use lodash?

[teiger313]

I have a very silly question.

If I am not mistaken formik uses 4 methods from lodash:

1. cloneDeep
2. isPlainObject
3. clone
4. toPath

Is it not better to implement somewhat identical methods within the project, that way formik can lower the amount of dependencies (lodash & lodash-es).

I mean there is probably a good (& obvious) reason why its there, just wandered.....what is it?

[johnrom]

There's a constant balance between maintaining our own versions of these methods, the cost of including lodash itself (anywhere from minimal to high, depending on a number of factors), and the "maintainer" cost of having to find other ways to perform these methods when the maintainer may just be very familiar with the lodash version. It's the modern version of the "why jquery" problem, but with the added caveat that our import of lodash functions means that if our users import those same lodash functions, they are actually saving file size by using the same imports, if done correctly.

I will say that I am really not an expert at webpack's tree-shaking, but it is my understanding that in certain environments it is very effective at cutting out the unused bits of lodash, so the cost of inclusion is very low, while in other environments, tree-shaking with lodash is pretty ineffective or nonexistent. It depends whether you're using ESM, CJS, browser, react native, etc. If I understand correctly, if you're in a browser build with ES modules, and you include lodash correctly, tree-shaking should work really well. I just ran webpack-bundle-analyzer, and confirm that lodash is way bigger than Formik when there is one single import like this (and the rest imported properly as I'll soon explain):

// this imports all of lodash and is not tree-shakeable
import { shuffle } from 'lodash';

Whereas by changing this one incorrect instance so that all of the imports across the project look like the following, it's an instant 24kb savings to the bundle.

// this is tree-shakeable with ESM
import shuffle from 'lodash/shuffle';

The various lodash calls I have across my project still amount to lodash being larger than Formik, so there's no way Formik would be including more than the necessary amount of lodash to run. Not to mention, if Formik maintained its own cloneDeep and I imported cloneDeep for my project, there would now be more code than before since cloneDeep would be duplicated. Instead, my project and Formik itself import the same lodash methods, saving file size and bandwidth.

[johnrom]

Also, since I just breezed past some complex topics like ESM and CJS, here's a pretty good explainer:

https://dev.to/iggredible/what-the-heck-are-cjs-amd-umd-and-esm-ikm

And some background on imports with ESM:

https://www.blazemeter.com/blog/the-correct-way-to-import-lodash-libraries-a-benchmark

[johnrom]

And finally, if you're in ESM, you should actually use:

import shuffle from 'lodash-es/shuffle';

Then you will achieve full de-duplication with Formik's bundled lodash. You should alternatively be able to alias lodash to lodash-es in your webpack configuration to achieve the same thing without changing your code.

This is because when lodash (built with CommonJS) is imported into an ESM project, it is actually wrapped similarly to what is described in my initial link above, and cannot be reused by Formik, which uses lodash-es which is "ESM-native" and requires no added code to use in ESM, reducing bundle size further.

[Teiger212]

Neat explanation and it made me wiser! So you're saying if imported the right way, there is not much overhead & added size to bundle.

I thought of another aspect of just not being dependant, or in other words, trying to be as 'self-sufficient' as possible. I guess if you use it just for the things that are really helpful AND there is no easy way to to it with native es6...lodash can be great