Lodash ships two generated builds, and the fp tree is separate code

One library, five module formats, and a per method escape hatch

Lodash covers iteration over arrays, objects and strings, manipulation and testing of values, and the composition of new functions from existing ones. Around that it offers a choice of shapes rather than one package. The formats listed are the main lodash package plus per method packages collected under the npm keyword lodash-modularized, lodash-es with babel-plugin-lodash and lodash-webpack-plugin, the lodash/fp variant, and lodash-amd.

The cherry-picking advice in the installation section is the practical version of that. Instead of loading everything:

$ npm i -g npm
$ npm i --save lodash

you can require a single method when the bundle is the constraint, and the installation section names browserify, rollup and webpack as the bundlers this is aimed at. What that advice does not do is tell you which methods are safe to import individually, so the decision ends up being trial and error against your own build.

For a browser with no bundler the answer is a script tag and a global, which is the least controlled of the three paths:

<script src="lodash.js"></script>

The core build is about 4 kB gzipped and the full build about 24 kB

Two downloadable builds, both linked to the 4.18.1 tag so the URL is pinned, plus CDN copies on jsDelivr. The core build is quoted at roughly 4 kB gzipped and the full build at roughly 24 kB, so the choice is a sixfold difference in what a browser downloads before your code runs a single call. The instruction is to review the build differences and pick one, which means the comparison itself lives on a wiki page rather than in the download section.

That gap has a consequence for anyone doing this properly. Nowhere in the documentation is there a list of the methods the core build contains, so you cannot answer "is the method I need in core?" from what is written in front of you. You either read the wiki page, or you measure your own bundle, or you take the full build and accept the size.

The Node story is different again, because the main entry in package.json is lodash.js, the full build at the root of the tree. A plain require in a server gets you all of it regardless of how many functions you call.

The Node example pairs lodash/array with lodash/fp/object

The installation section shows the three loading styles in one block, and the fp line carries its own warning in a comment: immutable auto-curried iteratee-first data-last methods. Then, under the heading for loading method categories, it shows two lines:

// Load method categories.
var array = require('lodash/array');
var object = require('lodash/fp/object');

The first is a category path, the second is a path into the fp tree. Two variables with parallel names, two different calling conventions, and nothing in the sample saying so. Anyone copying both lines gets a plain array category and an fp object category, where the methods take data last and return new values instead of mutating. It is the kind of example that produces a bug report about arguments being in the wrong order months later.

The surrounding lines are the reason to read the sample rather than skim it:

// 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');

The build differences wiki page is where the distinction between these paths is meant to be resolved.

pretest rebuilds the bundles, so npm test never runs against a stale dist

The test and build scripts in package.json are chained in a way that changes what a green run means. test is test:main plus test:fp, and pretest is npm run build, so the full build and the fp build are regenerated before any test executes. build itself is build:main and then build:fp, running node lib/main/build-dist.js and node lib/fp/build-dist.js in two separate source trees under lib/.

Two generators and two trees is the design point. The fp variant is not a wrapper that rewrites arguments around the main implementation; it has its own dist builder, its own module builder and its own test entry at test/test-fp. A change to one tree is not automatically a change to the other, and the CI only tells you about the tree you ran.

Style is a separate gate. validate runs style and then test, and the style scripts call jscs over lodash.js, the fp directory, the lib tree, perf/ and test/, with the rules in a .jscsrc file. jscs is a devDependency, so a contributor who has not installed it cannot run npm run validate at all, which makes npm install the first real step for anyone touching the source.

The documentation examples are executed by the test suite

One script in package.json is test:doc, which is markdown-doctest over doc/*.md, and a .markdown-doctest-setup.js file sits at the root to prepare the environment for it. The doc script is node lib/main/build-doc github followed by npm run test:doc, so generating the documentation and checking it are the same command.

This is a stronger guarantee than most libraries make, and it has an obvious limit. The examples that get executed are the ones in doc/*.md in this tree. Anything a user pastes out of a search result, a blog post or an answer in an issue tracker is not covered by it, which means a doctest pass tells you the canonical examples work and says nothing about the copy that has been circulating for two years.

Site generation follows the same pattern. doc:site runs node lib/main/build-doc site, and doc:sitehtml goes through optional-dev-dependency marky-markdown@^9.0.1 before node lib/main/build-site, with docdown in the devDependencies. The published documentation is an output of a build rather than a set of files edited by hand, so a stale website is a build problem, and a documentation fix only reaches the site if someone runs the right script.

engines pins node >=4.0.0 while the licence line promises modern environments

Two claims about supported runtimes sit next to each other and do not agree. The licence line says Lodash is released under the MIT license and supports modern environments, and the manifest declares engines node >=4.0.0, a runtime that predates most of what people mean by modern. Nothing in the manifest warns an installer away from an old Node, so the compatibility promise is a sentence rather than something npm can enforce.

The same manifest carries two more things worth knowing. private is true, which means this checkout is not the thing you publish from, and main is lodash.js, the full build sitting at the root of the tree rather than inside dist/. Node consumers therefore load the complete library, and dist/ exists as a committed directory holding the built files that the download section links to by tag.

On licensing, both the download section and package.json say MIT, and a LICENSE file is at the root, but the repository's own licence metadata does not resolve to a single identifier. If you vendor the source into a product, the LICENSE file is the document to read.

Feature-Complete is the stated destination, with 4.0.0 dating from 2016

The important notice at the top of the README says Lodash has received support from the Sovereign Tech Agency and will transition to the Feature-Complete maturity stage so that it stays stable, secure and sustainable long term. Governance is being rebooted, a draft charter is promised, and a Technical Steering Committee is already at work with its members listed in GOVERNANCE.md at the root of the tree.

Read that as a statement about what will not happen. Feature-Complete means maintenance, security work and stability rather than a stream of new methods, and the release record fits that shape: 4.0.0 shipped on 2016-01-12 and the current 4.18.1 on 2026-04-01, with 4.18.0 the day before it. The version has moved a long way in ten years while the major version has not moved at all. The last push to the repository was on 2026-09-11, so the tree itself is still being worked on.

Changelog and roadmap live on the wiki rather than in the tree, where a CHANGELOG file also sits at the root. Renovate handles dependency updates through a renovate.json file, and the devDependencies still pin lodash 4.17.20, the previous published version, as a build time dependency.

A threat model and an incident plan sit next to the source

Three files at the root of the repository are about security rather than code: SECURITY.md, threat-model.md and incident_response_plan.md. A utility library that is spread through every bundle in a company carrying a threat model and an incident plan is making a different claim from most libraries of its size, and the claim is about process rather than about any particular version.

The gap is discoverability. Neither the download section nor the notice names a reporting address, lists advisories, or links any of the three files, so a reader who finds a problem has to know to look in the root of the repository for where to send it. Compare that with the rest of the documentation, where the download section links raw files and the wiki link covers the changelog and the roadmap.

The rest of the tree explains how the library is kept honest. playwright.config.js drives browser level tests, perf/ holds the performance suite and is covered by the jscs style pass, vendor/ carries vendored code, and .gitattributes and .editorconfig sit alongside the source. No measurement is quoted anywhere in the documentation, so the performance claim in the repository description has no number behind it.

Editorial conclusion

Adopt Lodash when your codebase already depends on it or when the immutable, data-last fp calling convention is what you want, and adopt the core build or per method imports in a browser bundle where 24 kB gzipped is the number your users pay for. Do not adopt it in a greenfield project, because the repository documents no TypeScript entry point and the value it offers over the language's own array and object methods is not something the documentation argues for. Verify first which methods the core build keeps, since the download section sends you to a wiki page for that comparison instead of listing it, and then run the doctest suite so you inherit the documentation checks along with the library.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes