Lodash vs Lodash‑ES Import Interoperability in Repeatable Bundler Environments

Lodash / Lodash‑ES Integration

In a monorepo or multi‑project setup, developers often import from both lodash (CommonJS) and lodash-es (ESM). The goal is to maintain a repeatable build that is both size‑efficient and type‑safe across webpack, Rollup, and other bundlers.

Goal: Repeatable Development Environment

We need a strategy that guarantees deterministic tree‑shaking, avoids duplicate code, and preserves consistent TypeScript typings, while allowing the use of babel-plugin-lodash for CommonJS imports and native ESM imports for lodash-es.

Key constraints include:

• Side‑effect annotations in lodash vs pure ESM exports in lodash-es.
• Potential bundle inflation when both packages coexist without deduplication.
• Type definition differences that may surface when switching import sources.

Given these constraints, the following questions remain unresolved:

1. What aliasing or resolution strategy should we adopt to prevent duplicate code when both lodash and lodash-es are present?
2. How can we standardize the import transformation pipeline (e.g., babel-plugin-lodash vs native ESM imports) across all projects in the repository?
3. Which TypeScript type definitions (shared @types/lodash or @types/lodash‑es) should be used to maintain type consistency when switching between CommonJS and ESM imports?