Feature Request: Use lodash-es for ESM compliance

[Bengejd]

Description

Lodash inherently is not ESM compliant. This results in numerous warnings being thrown about potential optimization bailouts in Angular. For example, this is what I see when I run a production build that utilizes i18n:

▲ [WARNING] Module 'lodash/get' used by 'node_modules/i18n-js/dist/import/I18n.js' is not ESM
▲ [WARNING] Module 'lodash/has' used by 'node_modules/i18n-js/dist/import/I18n.js' is not ESM
▲ [WARNING] Module 'lodash/merge' used by 'node_modules/i18n-js/dist/import/I18n.js' is not ESM
▲ [WARNING] Module 'lodash/uniq' used by 'node_modules/i18n-js/dist/import/Locales.js' is not ESM
▲ [WARNING] Module 'lodash/camelCase' used by 'node_modules/i18n-js/dist/import/helpers/camelCaseKeys.js' is not ESM
▲ [WARNING] Module 'lodash/repeat' used by 'node_modules/i18n-js/dist/import/helpers/formatNumber.js' is not ESM
▲ [WARNING] Module 'lodash/sortBy' used by 'node_modules/i18n-js/dist/import/helpers/numberToHuman.js' is not ESM
▲ [WARNING] Module 'lodash/zipObject' used by 'node_modules/i18n-js/dist/import/helpers/numberToHuman.js' is not ESM
▲ [WARNING] Module 'lodash/range' used by 'node_modules/i18n-js/dist/import/helpers/timeAgoInWords.js' is not ESM

CommonJS or AMD dependencies can cause optimization bailouts.
For more information see: https://angular.dev/tools/cli/build#configuring-commonjs-dependencies

Obviously, this isn't ideal. I'm unsure if optimization bailouts are actually occurring, but regardless, this module should strive to be ESM compliant where it's easy to be via switching which flavor of lodash is being leveraged.

Describe the solution

Lodash has a number of build flavors available, one of them being lodash-es, which would allow the project to be ESM compliant out the gate with minimal changes required, my suggestion would be to update the package.json from:

  "dependencies": {
    ...
    "lodash": "*",
    ...
  },
  "devDependencies": {
    ...
    "@types/lodash": "*",
    ...
  },

to this:

  "dependencies": {
    ...
    "lodash-es": "*",
    ...
  },
  "devDependencies": {
    ...
    "@types/lodash-es": "*",
    ...
  },

As well as import statements from:

import camelCase from "lodash/camelCase"; to import camelCase from "lodash-es/camelCase"; this would allow the package to be considered ESM compliant from Angular's perspective, while maintaining functionality and dependency on lodash.

I am happy to submit a Pull-request if you agree with the approach. Should be relatively quick to whip up I'd imagine.

[NataliaDrause]

I'd like to confirm that i18n-js's use of lodash also leads to hard crashes at runtime in Metro-bundled React Native apps, specifically due to: require('util').
This comes from lodash's internal _nodeUtil.js.

The logged error during the crash:
ReferenceError: Property 'require' doesn't exist

The error occurs in React Native 0.79+ where they changed package exports support: https://reactnative.dev/blog/2025/04/08/react-native-0.79#metro-faster-startup-and-package-exports-support

A solution would be for i18n-js to use lodash-es as suggested above, or possibly have selective imports from lodash (only import what is needed), just like it is done in some other packages.

Current workaround in the app is to apply a patch:

// metro.config.js
config.resolver.unstable_enablePackageExports = false;

// babel.config.js
presets: [['babel-preset-expo']], // instead of 'module:@react-native/babel-preset'

Ref.: expo/expo#36551

[matthewtusker]

I'm in the middle of trying to strip out Lodash from our application in favour of as much vanilla JS as possible, and to reduce bundle sizes. The stripping out is going fine, but since i8n uses Lodash, I can't get the bundle size any smaller. Switching to lodash-es will make applications which require i18n much smaller, so I'm in favour of switching. @Bengejd I would suggest going ahead and raising the PR, so it can be discussed there.