lodash-es
Lodash exported as ES modules.
About
Lodash exported as ES modules.
What detecting lodash-es tells you about a site
Spotting lodash-es rather than plain lodash tells you the team cares about bundle size and tree-shaking. It is the ES-module build, so individual functions like debounce or cloneDeep can be statically analysed and dropped if unused, which only matters to someone who has thought about what ships to the browser. Its presence usually points to a modern bundler (Vite, Rollup, esbuild, webpack 5) and a codebase that leans on utility functions for collections, deep cloning and throttling rather than reimplementing them. It is a pragmatic, slightly old-school choice: a team comfortable with a big toolbox over hand-rolled helpers.
Why the exact lodash-es version matters
Lodash has been stable for years, so the major version rarely shifts behaviour, but the exact build still matters for one reason: prototype-pollution advisories have hit specific patch ranges over the library's history. Seeing an old pinned version can flag an unpatched dependency. The es variant also signals whether the team adopted the tree-shakeable distribution early or late, which is a small dating clue about when the front-end tooling was last modernised.
lodash-es in a real-world stack
When you find lodash-es in a bundle, it rarely travels alone. Modern bundlers like Vite or Rollup, and often alongside date and validation utilities in the same toolbelt.
Quick facts
npm install lodash-esHow Sourcemap Explorer detects lodash-es
lodash-es ships as v4.18.1, published 2026-04-01 and carries 0 direct dependencies, 71 versions on the registry. Those exact numbers are the footprint Sourcemap Explorer matches when lodash-es rides inside a deployed bundle — here is how the detection works.
We catch lodash-es from two complementary signals: bundled source paths and the embedded package.json. Modern bundlers (webpack, Vite, esbuild, Rollup, Turbopack) preserve the original node_modules/lodash-es/ paths inside the JavaScript sourcemap's sources[] array — that's the canonical signal. When the matching package.json is also captured in sourcesContent[], we read the exact version field — patch number included. No regex guessing, no version inference.
- 1
Confirm the site exposes sourcemaps
In DevTools Network, check the response headers of any application script for `SourceMap` or `X-SourceMap`. Failing that, fetch the script's last 4 KB and look for a `//# sourceMappingURL=` comment — that map is where the `lodash-es` paths live.
- 2
Find the package in the bundle
Open DevTools → Network → reload. Click any application script and look at its sourcemap. Inside, search `sources[]` for entries matching `node_modules/lodash-es/` — every match confirms the package is bundled. The matching `sourcesContent[i]` for `node_modules/lodash-es/package.json` gives you the exact installed version.
- 3
Read the version directly from package.json
Run `jq -r '. as $m | $m.sources | to_entries[] | select(.value | endswith("node_modules/lodash-es/package.json")) | $m.sourcesContent[.key] | fromjson | .version' bundle.js.map`. Sourcemap Explorer automates the same query in the popup.
Major releases of lodash-es
When each major version first landed. Major bumps are where breaking changes live, so this timeline is the fastest way to date the lodash-es version a site actually ships against the ecosystem.
Recent security advisories for lodash-es
The 5 most recent advisories affecting some versions of lodash-es, aggregated from OSV.dev (GitHub Advisory + CVE data). A listing here doesn't mean the version a given site ships is affected — each advisory applies to a specific version range. Sourcemap Explorer reads the exact bundled version so you can check it against these ranges.
lodash vulnerable to Code Injection via `_.template` imports key names
lodash vulnerable to Prototype Pollution via array path bypass in `_.unset` and `_.omit`
Lodash has Prototype Pollution Vulnerability in `_.unset` and `_.omit` functions
Regular Expression Denial of Service (ReDoS) in lodash
Command Injection in lodash
Recent versions
lodash-es README
Live mirror of the GitHub README, for reference. Updated whenever the repo's default branch changes.
lodash v4.18.1
Site | Docs | FP Guide | Contributing | Wiki | Code of Conduct | Governance | Twitter | Chat
[!IMPORTANT] As announced on the OpenJS Foundation blog, Lodash has received support from the Sovereign Tech Agency and will transition to the Feature-Complete maturity stage so that it remains stable, secure, and sustainable long-term. As part of this effort, Lodash is rebooting its governance. A draft charter will be published shortly. The upcoming Technical Steering Committee (TSC) is already at work. For transparency, its members are listed in GOVERNANCE.md.
The Lodash library exported as a UMD module.
Generated using lodash-cli:
$ npm run build
$ lodash -o ./dist/lodash.js
$ lodash core -o ./dist/lodash.core.js
Download
Lodash is released under the MIT license & supports modern environments.
Review the build differences & pick one that’s right for you.
Installation
In a browser:
<script src="lodash.js"></script>
Using npm:
$ npm i -g npm
$ npm i --save lodash
In Node.js:
// Load the full build.
var _ = require('lodash');
// Load the core build.
var _ = require('lodash/core');
// Load the FP build for immutable auto-curried iteratee-first data-last methods.
var fp = require('lodash/fp');
// Load method categories.
var array = require('lodash/array');
var object = require('lodash/fp/object');
// Cherry-pick methods for smaller browserify/rollup/webpack bundles.
var at = require('lodash/at');
var curryN = require('lodash/fp/curryN');
Why Lodash?
Lodash makes JavaScript easier by taking the hassle out of working with arrays,
numbers, objects, strings, etc. Lodash’s modular methods are great for:
- Iterating arrays, objects, & strings
- Manipulating & testing values
- Creating composite functions
Module Formats
Lodash is available in a variety of builds & module formats.
FAQ
What is lodash-es used for?
Lodash exported as ES modules.
How can I tell if a website is using lodash-es?
Open the page in Chrome with the Sourcemap Explorer extension installed and read the Stack tab. We catch `lodash-es` from two complementary signals: `node_modules/lodash-es/` paths inside the JavaScript sourcemap, and the embedded `package.json` we read for exact-version detection. Without the extension you can do the same lookup manually in DevTools — the steps are listed in the "How Sourcemap Explorer detects" section above.
How do I find out which version of lodash-es a website is running?
Read it straight from the site's JavaScript sourcemap. When a build ships source maps, the bundled `lodash-es/package.json` carries the exact `version` string — Sourcemap Explorer extracts it in one click on the Stack tab, and you can do it by hand in DevTools by opening the `.map` file and searching for `node_modules/lodash-es/package.json`. That is far more reliable than inferring the version from an asset-hash or a `?ver=` query string, which is all surface-level detectors have to go on. The current npm release is 4.18.1, but real deployments frequently run an older pinned version — which is exactly why reading the bundled number matters.
What is the latest version of lodash-es?
4.18.1, as published on the npm registry. The "Recent versions" table on this page lists the most recent 8 releases with their release dates. Sourcemap Explorer reports the version actually bundled into a site, which can lag the latest release by months on real-world deployments.
Is lodash-es actively maintained?
Actively maintained — the package is shipping new releases at a steady cadence. The last published release was 2026-04-01. Source code: https://github.com/lodash/lodash.
Does lodash-es have known security vulnerabilities?
5 recent advisories affecting some versions of lodash-es are listed in the "Recent security advisories" section above, aggregated from OSV.dev (GitHub Advisory + CVE data). Whether a particular site is exposed depends entirely on the exact version it ships — each advisory applies to a specific version range, not to the package as a whole. That is why the precise bundled version matters: Sourcemap Explorer reads the version a site actually runs, so you can check it against the affected ranges instead of assuming the latest release is what's deployed.
Where can I read more?
Project homepage: https://lodash.com/custom-builds. Source code: https://github.com/lodash/lodash. Published on npm: https://www.npmjs.com/package/lodash-es. Licensed as MIT.
Detected by Sourcemap Explorer
When a bundle ships sourcemaps, we read the embedded package.json for lodash-es and report the precise version (the registry's latest is v4.18.1, published 2026-04-01; the bundled copy is often older). Without sourcemaps, an import / require in the page's scripts is enough to flag it.