I considered lodash-es, but its usage seems rarer in many existing popular JS packages, so sticking with module-specific "lodash/foo" imports should ensure we are tree-shakable, while also using the version of lodash that many other packages will already have as a dependency (and instead avoid yet another dependency being installed in end users' projects). Also considered projects like radash, typedash, etc, but avoiding them for the same reason as lodash-es. We do only use a couple utils (debounce, throttle, omit) for what it's worth.
This should make sure we are tree-shakable in all/most end-user bundlers.
This is a helpful reference on this front https://itnext.io/lodash-es-vs-individual-lodash-utilities-size-comparison-676f14b07568
I considered lodash-es, but its usage seems rarer in many existing popular JS packages, so sticking with module-specific "lodash/foo" imports should ensure we are tree-shakable, while also using the version of lodash that many other packages will already have as a dependency (and instead avoid yet another dependency being installed in end users' projects). Also considered projects like radash, typedash, etc, but avoiding them for the same reason as lodash-es. We do only use a couple utils (debounce, throttle, omit) for what it's worth.