ATRIUMsearch → argument graph
Audio · 2026-01-22 · 57m · 6 moments

Next-Gen JavaScript Package Management with Ruy Adorno and Darcy Clarke

Package management sits at the foundation of modern software development, quietly powering nearly every software project in the world. Tools like npm and Yarn have long been the core of the JavaScript ecosystem, enabling developers to install, update, and share code with ease. But as projects grow larger and the ecosystem more complex, this older The post Next-Gen JavaScript Package Management with Ruy Adorno and Darcy Clarke appeared first on Software Engineering Daily. ✦ AI generated

timeline · colored by role

01
Claim

Package management innovation in JavaScript has historically been limited to client-side behaviors, while the registry APIs have remained largely unchanged for over 15 years.

Darcy Clarke argues that while package manager clients like Yarn and pnpm have innovated, the underlying NPM registry APIs have remained stagnant for over 15 years, creating an opportunity for server-side investment.

transcript

Darcy Clarke: What you would have seen in terms of innovation and package management for JavaScript in the last decade and a half was only focused on the client side behaviors. And so when Yarn came out and PNPM came out around the same time... these were just net new clients that still interacted with the same APIs that the NPM client did... And those APIs and those endpoints really haven't changed in 15 plus years.

rebuts · 2

02
Mechanism

A significant inefficiency in the current ecosystem is that every developer must independently resolve the dependency graph for the same packages, representing massive redundant computation.

Darcy Clarke identifies that redundant compute—every developer independently resolving the same dependency graph—is a core inefficiency, which Volt aims to solve with a centralized global cache through its serverless registry.

transcript

Darcy Clarke: Part of the big problem that we see and have historically seen is a lot of wasted and redundant compute happen in all of our machines. So if you, Josh, and me, and Roy all install the same package, we all have to resolve the dependency graph at that edge, which seems really wasteful in terms of opportunities to cache and have a centralized understanding of the dependency graph.

provides context · 1

03
Fact

Semver ranges are not part of the actual Semver specification, creating a hidden complexity that most developers take for granted.

Darcy Clarke explains that the Semver specification only codifies what a version is, not ranges—a fact most developers don't realize, and which contributes to the complexity of dependency resolution.

transcript

Darcy Clarke: There is no actual specification. There's like a quasi specification or standard for ranges... So every time we say Semver, we're kind of actually, we're stealing a term that actually doesn't have any basis for the ranges. Like ranges have not been codified in the Semver spec. Just so everybody knows, if you want to go check out the Semver spec, you're going to find that it only codifies what a version is. It doesn't codify ranges.

explains mechanism · 1provides context · 1

04
Context

The JavaScript ecosystem solved the diamond dependency problem uniquely by allowing multiple versions of the same package to coexist in a project through nested dependencies.

Darcy Clarke explains Isaac Schlueter's insight that allowed JavaScript to sidestep a key limitation of ecosystems like Java—rather than forcing one version, JavaScript nests multiple versions of the same package, which is both a strength and source of complexity.

transcript

Darcy Clarke: The beautiful thing about the JavaScript ecosystem is many years ago, Isaac Schlueter, who created NPM... was able to figure out that, hey, we can actually get around this problem by allowing multiple versions of the same thing to exist in a project, nesting these dependencies... And that's a beautiful way to kind of resolve that problem.

provides context · 1

05
Mechanism

Volt's CSS-inspired query selector language is a powerful innovation that allows expressive, composable selection of packages by metadata, relationships, and state across projects.

Darcy Clarke and Ruy Adorno describe Volt's CSS-inspired query selector syntax, which allows developers to select packages by metadata, security status, or relationships, and apply operations like config updates across many projects at once.

transcript

Darcy Clarke: This language is very much inspired by CSS... it's honestly, I think, the coolest thing that we have... The great thing here is you can get and set and remove or unset values in your package.json file. And utilizing a query selector syntax, you can imagine you can start to share configs, you can share dependency definitions... across your projects very easily.

extends · 1

06
Mechanism

Volt integrates with security vendors like Socket to provide real-time, queryable malware and CVE scanning, letting developers gate installations on whether a package has been scanned.

Darcy Clarke explains Volt's approach to supply chain security: partnerships with vendors like Socket provide enriched metadata, and a malware query selector lets developers refuse to install packages until they've been scanned, or retroactively find malware that slipped through.

transcript

Darcy Clarke: We have default queries that we're trying to prevent malware from getting into, but sometimes these security companies can be slow. NPM has historically been slow to realize that there is malware being distributed. And so... you can actually opt in to the selector that we have actually called scanned. And so you can choose to refuse to even install stuff before it's essentially scanned.

extends · 1

Highlight slides
Related episodes