Migrate from lodash to lodash-es

[Bengejd]

PR Checklist

PR Structure

• This PR has reasonably narrow scope (if not, break it down into smaller
  PRs).
• This PR avoids mixing refactoring changes with feature changes (split into
  two PRs otherwise).
• This PR's title starts is concise and descriptive.

Thoroughness

• This PR adds tests for the most critical parts of the new functionality or
  fixes.
• I've updated any docs, .md files, etc… affected by this change.

What

This PR migrates usage of lodash to utilize the lodash-es build variant for better tree-shaking support.

Why

lodash-es is the ESM build of lodash, which allows bundlers to tree-shake unused utility functions rather than including the entire library. Since this package targets modern bundler environments, using lodash-es reduces the final bundle size for consumers. It also addresses issues brought to light in #111.

Because lodash-es ships pure ESM, Jest cannot consume it directly in its default CommonJS environment. To support this, two changes were made to the dev/test setup:

• @babel/preset-env was added and configured via babel.config.js to transform ESM to CJS at test time
• transformIgnorePatterns in jest.config.js was updated to allow lodash-es to be transformed (Jest skips node_modules by default)

All tests are passing.

Known limitations

N/A

[fnando]

I just released 4.5.4-alpha.0 with this change. I tested this on browser, browser with importmaps, react-native and react-native with expo. They all worked! I'm going to give it another try on the weekend, and make a release if everything goes well!

[geoffharcourt]

@Bengejd would you consider using https://es-toolkit.dev/compatibility.html here? It's API-compatible with lodash/lodash-es, but much, much smaller.

[geoffharcourt]

Would it be possible to avoid the subdirectory-style imports and move to import { functionname } from 'lodash-es'? Asking because it's an impediment to aliasing lodash-substitutes like es-toolkit.

[Bengejd]

@Bengejd would you consider using https://es-toolkit.dev/compatibility.html here? It's API-compatible with lodash/lodash-es, but much, much smaller.

I believe that would be a decision that @fnando would have to make, as that fundamentally changes what the library depends on. Whereas this PR is simply changing the flavor of lodash build that we're using (old CJS build vs ESM build). The fundamental library underneath is still the same, we're just pointing it to a more modern build variant.

I encourage you to make your case in a separate PR or issue though, as the request is out of scope for this one at this time.

[geoffharcourt]

@Bengejd makes sense. My second comment (about import format) should still be possible and makes user-level overrides much easier to accomplish if that's possible to consider.

[Bengejd]

@geoffharcourt that seems reasonable to me. @fnando what are your thoughts?