Evolving Yarn

November 11, 2025

3 min read

Lead Yarn maintainer

Yarn’s first release was in 2016. Its first stable release occurred in 2017. In 2019 we announced a large rewrite of the project to make it more modular and easier to maintain over the long term. The architecture we chose served us well, and here we are, six years later. The landscape changed considerably since then; what lessons did we learn?

JavaScript tools grow in scope

JavaScript started with a Unix philosophy of small, composable tools. Eslint, Prettier, Esbuild, Jest, and many more. Your stack was usually built from scratch by combining these tools, and adding new ones as needed.

But since started to change a couple of years ago. With frameworks like Create React App or Next.js we started to shift towards more opinionated stacks. They were still using different tools under the hood, but they provided a more cohesive experience for developers.

The next step of course was to start merging these tools together, so the maintainers had full control over the experience they provided. From Biome to Oxlint, our tools started to gain more responsibilities.

This kind of evolution doesn’t come without its own challenges. Can these aggregate projects reach the same level of maturity as their individual components? How do we ensure that they remain maintainable?

Project management

Yarn also went through similar evolutions. Initially intended as a package manager, we ended up subsuming features from third-party tools such as Lerna or patch-package. This turned out to be a good decision, as both features became staples of the JavaScript ecosystem.

Today, as we look into 2026, I wonder: in which direction should we go next? I work in developer experience, and I still see rough edges in the way we manage projects. Tools appeared that attempted to solve them but, because they aren’t directly integrated with our package manager, they can’t be standard practices, and sometimes aren’t able to leverage the knowledge Yarn has about the project.

In particular, I find the following areas intriguing and worth exploring:

Task management: Various tools exist to manage tasks, from the native yarn workspaces foreach to third-party solutions like Turborepo or Lage. Can we learn from them?
Precommit scripts: In the same way, tools exist to setup your precommits so you can easily run tasks. If Yarn supports native task management, could we natively provide git hook triggers?
System management: A couple of years ago I worked on the first iteration of Corepack. The idea was to provide a way for Node.js to allow managing Yarn and pnpm versions. Today I wonder; shouldn’t that go the other way around? Shouldn’t Node.js be a dependency of your project?

Expanding Yarn’s scope and capabilities doesn’t come without risks. We’re a small project, and we need to be careful not to overreach. Initiatives like these will require not only resources but also a commitment to maintain them over time.

Still, the story is appealing.