v4.18.1 remains useful when a codebase already speaks Lodash
Lodash packages familiar operations on arrays, objects, strings, functions, and values behind a consistent API. Methods such as get, merge, groupBy, debounce, and cloneDeep solve small problems that otherwise produce repeated local helpers. The library also supports iteratee shorthands, chaining, and a functional build. In an established application, that shared vocabulary can make old code easier to read than a mixture of hand-written loops and subtly different utility functions.
The calculation changes in new code. JavaScript now has Object.entries, optional chaining, nullish coalescing, Array.prototype methods, structuredClone, and other built-ins that cover part of Lodash's old territory. A dependency may still earn its place for debounce, deep comparison, path operations, or a large collection pipeline. Adding the full API for one trivial helper is harder to defend, especially when a teammate must learn both the platform operation and Lodash's variation.
What happened when we ran it
Our sandbox installed commit 2b5e6f7 in 36 seconds. npm added 496 packages, and the resulting development environment occupied 188 MB on disk. The build completed in 4 seconds, then the repository's test command passed in 15 seconds. npm audit reported 0 known vulnerabilities across all four severity levels. Our test method used a fresh unprivileged Debian container with 3 CPUs, 8 GB of RAM, Node 22, and no secrets. These figures describe the checkout and developer toolchain we tested, rather than the size or speed of code a consumer ships.
The measured repository was small before installation: 65 files, roughly 51,010 source lines, and 2.1 MB checked out. Our scan found 8 CI workflow files and a tests directory, with no Dockerfile. The package manifest has no listed runtime dependencies, so the 496 packages belong to development, build, documentation, compatibility, and test work. That distinction matters when judging supply-chain exposure in an application versus the maintenance cost of contributing to Lodash itself.
The full browser build is about 24 kB gzipped
The Lodash README lists a core build at about 4 kB gzipped and the full build at about 24 kB gzipped. npm users can load the main package, lodash/core, lodash/fp, method categories, or a single method such as lodash/at. An ESM distribution also exists as lodash-es. Those choices make bundle criticism more specific: a careless import can cost more than a deliberate per-method or ESM setup.
Module choice also affects maintenance. The main package is UMD, while lodash-es serves ESM users and lodash/fp changes argument order plus currying behavior. Those are separate contracts, not interchangeable spellings. Pick one convention for a project and enforce it through imports. Mixing full-package calls, per-method packages, and FP helpers makes upgrades harder to reason about and can defeat the size reduction that motivated cherry-picking in the first place.
v4.18.1 fixed a publishing gap that CI missed
The v4.18.1 release notes describe a useful failure. Internal dependencies changed, but a mapping in the separate build tool did not. The published modular builds then threw a ReferenceError in template and fromPairs. Maintainers fixed the release on April 1, 2026, and plainly said the defect passed CI because the tested source was not the same artifact users installed. Published-package smoke tests belong in a downstream team's upgrade check.
Lodash's repository is active despite its feature-complete direction. GitHub showed 61,342 stars, 121 combined issues and pull requests, and a push on October 1, 2026. The latest release was 6 months old, while October pull requests covered dependency updates, documentation, cloning, string conversion, and merge work. That mix reads as maintenance of a mature contract, not abandonment. The OpenJS-supported governance reboot also names a Technical Steering Committee in the repository.
Two current edge cases can change program behavior
Issue 6274 demonstrates truncate looping forever when its separator regex can match an empty string. The report says one CPU core reaches 100%, and two open pull requests propose advancing the regex index after an empty match. Issue 6228 shows cloneDeep cloning Map values while retaining original key references, unlike structuredClone. Both cases are narrow, reproducible reasons to test semantics instead of trusting a method name.
A newer report, issue 6292, shows camelCase('APIs') producing apIs rather than apis. An open pull request proposes a fix, but the report also illustrates why mature string helpers still need fixtures drawn from your own identifiers. Acronyms, separators, Unicode, and casing conventions are product rules as much as library behavior. Pin the version and keep representative names in application tests when output becomes a URL, key, or generated symbol.
Lodash still earns its place when replacing it would churn a working codebase or when several distinctive helpers appear throughout the project. Our 15-second passing test run and clean audit support that conservative choice. A fresh application should begin smaller. Use native syntax for obvious operations, measure the shipped bundle, and add Lodash or a modern alternative when a repeated problem justifies another dependency and another set of semantics.