console.log()

Is npm Enough? Why Startups are Coming after this JavaScript Package Registry

Share via Twitter Share via Facebook Share via Linkedin Share via Reddit

There’s been significant disruption in the JavaScript package management space recently. While npm continues to be the de facto JavaScript 1) package registry and 2) package manager used in Node.js runtime environments, it is worth discussing how these shifts factor into the larger Problem of JavaScript Code Delivery. Specifically, I am thinking of the recent appearance of Deno’s JSR (the JavaScript Registry) and vlt’s vsr (vlt Serverless Registry). Deno markets JSR as an “open-source package registry for modern JavaScript.” It was developed by Ryan Dahl, creator of the Node.js JavaScript runtime and Co-Founder & CEO of Deno, and has some good momentum within the JS community. Meanwhile vsr has also been generating some buzz since it debuted in November 2024 at NodeConf EU in Ireland. The folks at vlt position vsr as offering “a streamlined, privacy-first environment for private development and seamless distribution.” Created by Ruy Adorno, Darcy Clarke, and Isaac Schlueter (the creator of npm), vsr is looking to make inroads on the space. Both Deno and vlt have deep DNA in the Node and npm space, and both are entering the package registry space by way of package management—let’s talk about why.

 

Package Managers

So what even is a package manager? Software packages are archived files that include a computer program along with metadata needed for its deployment. Package managers find, install, maintain and uninstall software packages. They also manage information on software dependencies and versions to avoid compatibility issues and missing requirements. While computer operating systems call for managers like Linux’s Yellowdog Updater Modified (YUM), Debian Linux’s dpkg, Arch Linux’s pacman, Windows’s WinGet, and macOS’s Homebrew, software app developers require managers to handle packages necessary for building applications.

RedMonk has been following package management forever, but what has only become more true in 2025 is that building modern applications requires pulling down and managing a boatload of dependencies. Running the command npm install in the CLI for a React Native project, for instance, can add close to 1,500 dependencies to the package.json file. What is more, these dependencies often have their own dependencies. This heaviness is not exclusive to JavaScript and TypeScript applications, but has been a sticking point in the SPA wars. JS has a bias to feature development. Setting aside the question of whether all of these dependencies are necessary, even the most pared down applications have enough packages that a third party manager becomes essential. Managers like npm (JavaScript), CPAN (Perl), PEAR (PHP), and PyPI (Python), all promise to simplify dependency management. Which brings us to the entwined subject of package registries.

Because package managers are responsible for pulling down external repositories, they must integrate tightly with software repositories like GitHub, GitLab, and BitBucket that store code. They also depend upon package registries to publish and share these packages. It is unsurprising that GitHub and GitLab offer package hosting as a service. Packages, after all, are just code that is published and consumed in a particular manner.

 

Managing the JS Ecosystem

In the JavaScript (JS) ecosystem, package managers are clients to and limited by npm’s Public Registry API/ infrastructure. Whoa, whoa, whoa, Kate. I thought you said that vsr and JSR were going to replace npm!? Nope. While all registries facilitate publishing and sharing code, today, for complex technical reasons relating to dependencies, ecosystem lock-in (CI/CD pipelines, workflows), integration with the Node.js runtime, and framework interdependency issues (React, Angular), there are few if not zero alternative JS registries to npm. This means that the Bun runtime, pnpm (Performant Node Package Manager), and Yarn (a JS package manager for the Node) all use the npm registry. Today JSR and vsr are both essentially npm-compatible layers. According to the JSR website: “JSR isn’t a replacement for the npm registry; it’s a superset of npm.” Although the vlt team is marketing vsr as a “drop-in replacement for your existing package manager” (presumably npm), like JSR, vsr does not replace the npm registry but instead offers privacy and a more optimized developer experience through additional features such as “dependency query selector syntax, export formats (including Mermaid) & GUI experience to help lower the bar for understanding your dependency graphs.”

Reasons to follow shifts in JS package management are numerous. For one, there seems to be money to be made by disrupting npm. VCs recognize this opportunity and have backed Deno (Series A from Shasta Ventures, Insight Partners, and Sequoia Capital, among others) and vlt (Pre Seed from Accel and Feross Aboukhadijeh). While Deno has several products in addition to JSR, including a runtime, web framework, and hosting, vlt is going all-in with their private, feature-rich registry. The value prop of package registries, and npm for the JS community specifically, has always been developer experience. No one wants to return to the pain of writing shell scripts, much less the pip days or managing Ruby gems. In fact, Schlueter has been vocal about creating npm to resemble the better experiences afforded by other languages such as PHP’s PEAR and Perl’s CPAN.

In the registry space, developer experience is everything so the question of whether these new npm-compatible registries created to serve the TypeScript and JavaScript communities will succeed seems to hinge on whether npm is adequately serving this need. The new crop of package registries from the creators of npm (Schlueter) and Node (Dahl) could be the consequence of a lot of complex signals such as 1) market size (the JS pie is enormous), market control (the majority of Node, JS, TS and other packages currently reside in a single place), and 3) developer demand for excellent experiences. However, it is this last one that I hear most about from creators. Consider Dahl’s explanation of today’s “distribution of libraries and modules”:

We don’t think NPM is ideal for that. There’s a lot of problems about that so we’ve built JSR to make this really simple and nice to distribute TypeScript and JavaScript.

Clearly there is a lot to say about JS package registries. Let’s take a step back and talk about why startups are going after this space, and what it reveals about the future of npm.

 

npm Today

Npm was initially released in 2010, and acquired by GitHub in 2020, two years after the Microsoft acquisition. When it comes to JS package management, npm is the undisputed market leader. For instance, the Software House’s 2024 State of Frontend Report found that npm is the most widely used package manager (56.6% of votes), followed by YARN (21.5%) and pnpm (19.9%), but when it comes to registries as infrastructure, it is the foundation upon which all JS packages are built—not just Node, but also React libraries, webpack, Typescript.

Although a few in the JS community at the time of the GitHub acquisition worried this was another Microsoft Embrace, extend, and extinguish ploy, many developers in the community welcomed the move because, unlike some other OSS projects, npm requires significant resources and community buy-in. This is certainly the message I gleaned from Chris Patterson, senior director of product management at GitHub, when I asked him about GitHub’s roadmap for npm:

So the primary roadmap for NPM is to keep it secure and highly reliable, and that has been, frankly, the work we’ve been doing for quite a while. You know, the sheer volume of package downloads that have to be searched, acquired, served, the amount of spam that is attempted to be uploaded, because it’s a broad attack surface, like all of these things, are significant efforts in terms of keeping a service like NPM very safe, very secure and highly reliable.

Everyone I spoke with for this piece emphasized that npm is a tremendous cost center, and this made the backing of a large cloud provider (Microsoft) under the auspices of an established code repository (GitHub) ideal. There are two aspects to the expense of running npm worth mentioning: technical costs and operational costs. The technical side is data storage, which is not inconsequential considering the registry’s scale and the number of downloads it has to support. Moving data around is not cheap, and as a pivotal web infrastructure npm can’t afford downtime. Presumably, post-acquisition this expense became more affordable as it could be absorbed into Microsoft’s own data centers. However, operations are where the real cost of npm balloons. In addition to the engineering labor of maintainers and office space (pre-acquisition npm had an office in downtown Oakland), the single largest expense of running this registry has been the raft of required lawyers. Naming disputes, squatting, trademark research, mediation all come at a significant expense.

Materially, npm needed a good home and deep pockets, but GitHub’s leadership also identified developer experience as core to their plans for the acquisition. In a blog post explaining the decision to acquire npm, they outlined three pillars for growth:

  • Invest in the registry infrastructure and platform. The JavaScript ecosystem is massive and growing quickly. It needs a rock-solid registry. We will make the investments necessary to ensure that npm is fast, reliable, and scalable.
  • Improve the core experience. We will work to improve the everyday experience of developers and maintainers, and support the great work already started on the npm v7 CLI, which will remain free and open source. Some bigger features that we’re excited about are Workspaces and improvements to the publishing and multi-factor authentication experience.
  • Engage with the community. We will actively engage with the JavaScript community to get your ideas and help us define the future of npm.

Unfortunately, there is an increasing feeling in the JS community that GitHub has abandoned these pillars. In fact, several folks I spoke with for this piece contend that npm is running in KTLO (Keep the Lights On) mode, and the project is suffering as a result. I like Theo Browne’s diplomatic phrasing:

the amount of effort [GitHub/Microsoft] put into maintaining and growing the npm ecosystem has been massive, even if the experience and quality of functionality we expect just hasn’t improved much since really old versions many years ago. I can’t honestly remember the last time the npm registry shipped a meaningful new feature, and I keep a close eye on that stuff.

Security is probably the most significant canary that npm as a project continues to require significant resources and active support. In the online developer communities I frequent, any news around npm tends to focus on bugs and exploits. Darcy Clarke’s well-publicized claim that there is a “massive bug at the heart of the npm ecosystem” criticizes the fact that manifests from npm packages are published independently from its tarball, which may be written locally, not always in a git repo. Meanwhile, developer forums on Reddit and Hacker News are awash with stories about malicious and spam npm packages. In addition to the lottie-player library exploit, which Jakub Pavlík, co-founder & head of engineering at Exaforce, explains: “highlighted the fragility of the NPM ecosystem’s security,” Phylum Research’s “The Great npm Garbage Patch” discusses: “the proliferation of spam packages in npm associated with the Tea protocol, a decentralized initiative that promises to compensate software developers in cryptocurrency for their open-source contributions.” There is also Alex Anderson’s “Squatting npm for Remote Code Execution,” which identified a potential exploit:

As a proof-of-concept, I registered various packages with names matching bin scripts in popular packages, which list their own bin commands. These bin commands are a benign wrapper which attempts to run the script the user would have expected.

A malicious actor could replace these benign scripts with anything they want (e.g. data exfiltration, modification, destruction; system shutdown etc.).

The Node community is particularly concerned about the state of npm. According to Robin Bender Ginn, Executive Director of the OpenJS Foundation:

JavaScript developer communities are telling us that they see real or perceived security and performance gaps with npm/GitHub. Consequently, the JavaScript ecosystem risks fragmentation, with new package registries emerging. This outcome is less than ideal due to the significant burden of maintaining registries, potential interoperability challenges, and evolving security compliance requirements.

 

npm’s Competition

All of this sturm und drang has fostered conditions ripe for competition, which Deno and vlt are answering. But they are not alone filling perceived feature gaps left by npm in the package management space. So what features do JS developers want? You can browse feature requests and error notifications in the GitHub Community forum devoted to npm (formerly located here). One popular request from 2021 is for dark mode, which Myles Borins answers: “At this time we are not going to be able to prioritize Dark Mode on npmjs.com.” For a quick laugh, the memes and continued pleas for dark mode are worth a scroll.

More seriously, some developers express disappointment in the lack of documentation on the official npmjs.com website. The security platform Socket arguably offers better package documentation than the npm registry (see comparison of the lodash package below). Moreover, UNPKG, a content delivery network for npm, allows users to extract and reference files inside of each packages’ zip file in ways npm is currently unable to. By providing insights into the package’s content, UNPKG provides actual code analysis.


 

What is the business?

The story of npm and the startups raises a significant question; namely, what is the business here? Npm is a financial sink, technically but more importantly in hard, ongoing operational costs—legal and otherwise. This was the basis for the initial acceptance of Microsoft/GitHub ownership, mandating that whoever owns it needs to have deep pockets. That surfaces two significant issues in my mind: first, Deno and vlt have received funding, but neither would presumably be accused of having deep pockets. Why and how should they be expected to be a better steward of npm or possibly its successor than GitHub? Second, what is the financial model that would turn npm from a cost center into a profit center? If these companies position themselves as providing a private registry, they are essentially recreating npm’s business model, which charges to host private packages. If they also offer a better developer experience this could have broad appeal, but whether the market agrees it accomplishes enough remains to be seen.

To wrap up this conversation about the landscape of JS package managers, npm, and package registries, I want to emphasize that I am following this space because it really matters. So much of the web relies on npm and Node, and this often overlooked and unsexy part of development should not receive short shrift owing to its seeming invisibility. Package managers and registries are essential infrastructure upon which developers and the internet rely. I’m excited to see the sort of improvements and optimizations the savvy folks who are pushing the limits of packaging software can build.

Disclaimer: GitHub, GitLab, and Microsoft are RedMonk clients. Deno and vlt are not currently RedMonk clients.

No Comments

Leave a Reply

Your email address will not be published. Required fields are marked *