The Future of Lodash

Just a few minutes ago we announced that a new chapter in Lodash’s history begins. A chapter full of hope, excitement, and hard work — leaving behind years of solitary maintenance to embrace a collaborative and sustainable model, at a time when the JavaScript ecosystem needs stability and coordination more than ever.

An undeniable reality

Lodash is a utility library with a long history. Although JavaScript has evolved greatly since 2012, today:

• 9.3 million websites use it.
• One-third of the top 10,000 sites also rely on it.
• On npm, it reaches 2.4 billion weekly downloads (combining all Lodash variants).

Directly or indirectly, many of us depend on Lodash every time we run npm i in any project.

Even with campaigns like “You don’t need Lodash”, dozens of tutorials exploring alternatives and migrations… time passes, and we still haven’t fully transitioned to other libraries or modern solutions — simply because finding the time and resources for that work is extremely hard. It’s an effort that rarely translates into tangible business value within sprints or KPIs.

Often, it’s easier to maintain something that already works than to reinvent the wheel — to rewrite it all just to end up, in time, with a new “legacy” stack facing the same fate.

It’s an uncomfortable truth that’s hard to accept — much like realizing that many software projects only have a brief window for innovation before becoming “legacy” and joining the vast fleets of code that keep the world running.

John-David Dalton (JDD) has done an incredible job over the years maintaining the library and keeping the ship afloat. It’s not easy to sustain such a popular library as a single person.

The plan

Lodash’s future will focus on making the project sustainable, based on the assumption that it is now feature-complete (ref).

Our philosophy:

• Simplify maintenance
• Offer a clear future to users
• Improve the security posture

These principles may evolve as we move forward and uncover unknown unknowns (issues we don’t yet know exist), but overall, we can expect the following:

Simplifying maintenance

For Lodash to remain viable over time, we need to distribute the decision-making and maintenance workload. The first step will be to establish a technical governance structure — moving from a Benevolent Dictator for Life (BDFL) model with John-David to a more plural one with a Technical Steering Committee (TSC) that shares responsibility and seeks consensus-based decisions. This will be a deep cultural change.

One of Lodash’s biggest current challenges is the technical burden of maintaining so many variants (lodash-amd, lodash._reinterpolate, lodash._getnative, lodash._basecopy...). The likely decision will be to deprecate many of these in favor of the main library.

One of the first things we need to restore is the continuous integration system, to land pending changes and ensure we don’t break compatibility. This will allow us to publish centralized releases in a single package with all utilities, rather than fragmented versions. Today, many libraries already let you install or bundle only the utilities you need, without carrying the whole library.

Improving the security posture

Security has historically been a sensitive point for Lodash, having suffered from incidents such as prototype pollution and ReDoS. This generated a flood of invalid vulnerability reports, draining much of JDD’s time.
To prevent this, triage (classification and prioritization of security reports) will become a shared team responsibility, as already happens in other OpenJS Foundation projects like Node and Express.

With the inclusion of a Threat Model, we can greatly simplify triage, better define our security policy, and help reporters understand what we consider valid or invalid (What is a Vulnerability and What’s Not? Making Sense of Node.js and Express Threat Models).

We’ll also formally adopt the Foundation’s CNA (ref) to handle incidents and request CVEs, improve reporting channels via GitHub Advisory, and document the process for security releases in an Incident Response Plan (IRP), as other projects already do.

Finally, once the project stabilizes and we define how the next major version will handle breaking changes, we may conduct an external audit to refine documentation and review potential vulnerabilities.

Offering a clear future

JavaScript is a dynamic language that evolves without breaking backward compatibility. This leads us to plan a progressive rewrite of the library using native functions under existing interfaces. That way, even if you’re using Lodash in a legacy project, it can still benefit from V8 engine optimizations without performance penalties.

Our next major version will likely limit compatibility to modern Node.js versions and browsers, allowing us to use current syntax. It will be a semver major release, but the migration shouldn’t be painful for users.

It’s clear that new features are not a priority — our focus now is on stability, clarity, and long-term trust.

Lessons learned from Express

In January 2024, we launched an ambitious plan to take Express to the next stage of its history as a framework (ref).

What we learned from Express is that sustainability doesn’t happen by inertia — it requires an active community, clear governance, and real support — both technical and financial. Changing the governance model, distributing responsibilities, and having the backing of the Sovereign Tech Agency were key steps in revitalizing the project.

Express 5.0 was finally released (after a decade of waiting!), and many of our plans came to life. You can read the full report.

We’re now applying a very similar strategy, philosophy, and set of priorities in Lodash — because we know it works and it’s far more sustainable.

The future

The truth is that even if these plans succeed and our ecosystem becomes more secure, sustainability remains an outstanding debt. As ironic as this meme:

Image from xkcd 2347 - Dependency

Yes, it’s 2025 and we’re still in the same place. Little has changed for many maintainers.

When a struggling library gets rescued by others, we often celebrate it. But the underlying problem remains: we are not sustainable. And believe it or not, Node.js has no employees — nor does Express. Most of your favorite maintainers — the people who build and maintain the libraries we all use to keep the world running — still aren’t paid in most cases.

As Robin Ginn says, “open source cannot rely on magic piles of money”.

Lodash and Express are fortunate to be under the OpenJS Foundation umbrella, where mechanisms like the Cross Project Council allow us to launch initiatives and share concerns that can change project trajectories. But many of the projects we all depend on aren’t that lucky.

We need more initiatives like Alpha Omega and Sovereign Tech Agency to keep helping projects move complex initiatives forward. We can’t keep ignoring that open source needs real funding to be sustainable. Open source is a public good — and it’s everyone’s responsibility to care for it and help it thrive.

And yes, I’m also looking for sponsors — especially companies — who want to help maintain the stack many of you use every day. Because sustaining free software is a shared responsibility.

Lodash continues to power the web, and with this new model, we hope it will also inspire a new generation of maintainers. If you work with JavaScript, if your company depends on open source libraries, or if you simply care about the future of free software — now is the time to get involved.