Yarn in Depth: Why & How

Rate this content
Bookmark

Since 2017 Yarn proved itself a pillar of JavaScript development incubating numerous features our ecosystem now heavily relies on. As years passed, as competitors improved, so did Yarn, and it's now time today to dive into the features and tradeoffs that make Yarn a truly unique gem of the JavaScript ecosystem.

Maël Nison
Maël Nison
34 min
09 Jun, 2021

Comments

Sign in or register to post your comment.

Video Summary and Transcription

Yarn is a package manager and project manager that prioritizes soundness and reliability. It offers workflows and features like zero-installs and workspace alignment. Yarn's success lies in its infrastructure and hidden gems. It has a modular architecture and is committed to the ecosystem. Yarn emphasizes correctness and is a better fit for those who value it.

Available in Español

1. Introduction to Yarn

Short description:

Yarn is a package manager for JavaScript, but it's actually more than that. It's intended to be a project manager that lets you manage scripts, split your application into stand-alone models, manage release cycles, monitor script usages, and enforce monorepo standards. Yarn values community contribution and relies on its contributors to make the project sustainable. It prioritizes soundness and ensures that issues in your application are not overlooked. Yarn aims to provide a reliable and dependable development environment.

Hi everyone, for those who don't know me, my name is Maer. I currently work at Datadog, a company focused around cloud monitoring, and I have been leading Yarn's development for a few years now.

Today we're going to extensively talk about what Yarn is and what it can bring you. I hope that by the end of this talk you will have a better idea of what makes this project unique in our ecosystem. So if you ask anyone, they will likely tell you that Yarn is a package manager for JavaScript and by that they would be right. But it's actually only part of the story. Yarn is not just a package manager, it's intended to be a project manager. And indeed, if you think about it, Yarn lets you manage scripts. It lets you split your application into stand-alone models. As we'll see later, it will also manage your release cycles, monitor script usages, or even enforces monorepo standards. All these tasks go far beyond the typical package manager and every release we make pushes the boundaries even further.

So it's a product manager which sounds nice, but how does it translate in practice? What are the things that we look for when we merge Peers that give the project what it is? Let's discuss core values. So the first thing to realize is that we are a community of contributors. Open source is a very taxing environment and most projects are struggling finding ways to make their work sustainable. Yarn isn't exempt of that. To help a bit, we rely a lot on our contributors to be the changes they want to see, to contribute back to the project they like. In practice, it means that our core team spends as much working on our infrastructure as on the product itself. Recently, we moved from Webpack to ESBuild to make building yarn easier. Multiple comments let's you build part of the Yarn binaries from sources. So you can easily try out independent features. Or even write them yourself and start using them in your project without waiting for them to be merged. Yarn is all about making it possible for you to experiment well past what we could offer by ourselves.

The second very important value we are always keeping in mind when developing on Yarn is soundness. Yarn must tell you if something is wrong in your application. It must not let it go unnoticed. It must not make uncontrolled assumptions. This may sound a bit rigid, and is the reason why you have so many problems with x is depending on y without listing their dependencies, but it's really critical. Because whether you alter applications or libraries, you need to have confidence that something that works now will also work on production or when installed by your customers. If something needs to break, then it needs to break early so that you don't get it later on when you're not prepared for it. Good practices.

2. Yarn's Impact and Workflows

Short description:

The JavaScript landscape is large and fast-paced. Yarn, as a package manager, aims to guide users and help them understand the tools they are using. Yarn prioritizes developer experience and aims to do the right thing by default. It eliminates the need for manual validation of project installation. Yarn's impact can be seen through stories of projects that have adopted it, including the Yarn repository itself. The Yarn team actively uses all features shaped into the core, which has positively influenced their work. Yarn also provides workflows, such as release cycles, to enhance development processes.

The JavaScript landscape is large, charges fast and has many opinionated people. As a package manager, we are uniquely positioned to help our users understand the tools they are using and guide you along the happy path. Not only using Yarn should solve a practical need, it should also contribute making you learn and become a better engineer along the way.

We reached the last one on this set, developer experience, doing the right thing by default. Let's take an example. In Yarn 1, there was a comment named Yarn Check. It was validating that the project was correctly installed. As a result, various companies had a policy of calling Yarn Check after every install, just to be sure that everything was okay. We removed this comment from Yarn 2 and can you guess why? The thing is, Yarn should do and already does the right thing by default. You shouldn't have to validate that your project is correctly installed, because it should be correctly installed from the get go.

So we've seen a bit of what Yarn claims to be. Let's talk a bit DevOps. What does Yarn can do for you, practically speaking? We're going to go over two interesting stories of projects who adopted it. One is a web open source project you may have heard of. The other is an internal application. Without surprise, the first one is Yarn itself. Before we dive in, let me tell you a funny story. Back in Yarn 1, we didn't actually use workspaces to develop Yarn, and it was a real problem because not only were bugs hidden from us, we also weren't directly confronted with the value of some important features. For example, when you use workspaces, it's very apparent that you need to be able to run a script in all your workspaces at once. However, since we didn't use those workspaces ourselves, it didn't seem like a huge deal to us at the time, and thus, the feature took a long time to come. Nowadays, we have an internal rule that the Yarn team needs to use all features shaped into the core, and I believe it has a strong positive impact on the work we've made so far. This is one reason why the Yarn repository is so important for us because it's where we experiment with a lot of features, not all of them being used by our users themselves. Anyway, let's talk about workflows.

The first one are release cycles. Our previous process was very simple. We had a file at the root of the repository, and each PR was expected to have one line to it. It worked fine, but after switching to a model repo, it wouldn't have scaled very well since we needed the ability to release each workflow by itself. So we developed the release workflow instead. The idea is that with each PR we merge, it has to include a little file created by Yarn that lists all the workspaces that have been changed by the PR and whether they will need to be part of the next release, and whether it will be a minor, a patch, or a major version. Our CI will validate that this file exists and its content, and at release time we simply need to tell Yarn to aggregate all the version files currently checked inside the repository into package bugs and charge log generation.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

pnpm – a Fast, Disk Space Efficient Package Manager for JavaScript
DevOps.js Conf 2022DevOps.js Conf 2022
31 min
pnpm – a Fast, Disk Space Efficient Package Manager for JavaScript
You will learn about one of the most popular package managers for JavaScript and its advantages over npm and Yarn.A brief history of JavaScript package managersThe isolated node_modules structure created pnpmWhat makes pnpm so fastWhat makes pnpm disk space efficientMonorepo supportManaging Node.js versions with pnpm
The Zen of Yarn
DevOps.js Conf 2022DevOps.js Conf 2022
31 min
The Zen of Yarn
In the past years Yarn took a spot as one of the most common tools used to develop JavaScript projects, in no small part thanks to an opinionated set of guiding principles. But what are they? How do they apply to Yarn in practice? And just as important: how do they benefit you and your projects?
In this talk we won't dive into benchmarks or feature sets: instead, you'll learn how we approach Yarn’s development, how we explore new paths, how we keep our codebase healthy, and generally why we think Yarn will remain firmly set in our ecosystem for the years to come.
Yarn 4 - Modern Package Management
JSNation 2022JSNation 2022
28 min
Yarn 4 - Modern Package Management
Top Content
Yarn 4 is the next major release of your favourite JavaScript package manager, with a focus on performance, security, and developer experience. All through this talk we'll go over its new features, major changes, and share our long-term plans for the project.If you only heard about Yarn without trying it yet, if you're not sure why people make such a fuss over package managers, if you wonder how your package manager can make your work simpler and safer, this is the perfect talk for you!
Security Controls in the JavaScript Supply Chain
JSNation 2022JSNation 2022
28 min
Security Controls in the JavaScript Supply Chain
The omnipresence of open-source software and low-barrier of entry on npmjs are serving as a catalyst for supply chain security incidents that are continuously impacting JavaScript developers. What can we do to protect ourselves?
Vite - The Next Generation Frontend Tooling
React Advanced Conference 2021React Advanced Conference 2021
21 min
Vite - The Next Generation Frontend Tooling
How will we build web apps in the future? Let's learn how esbuild and bundlers like Vite built on top of it work to see how it can speed up our dev workflows.
Taming the State Management Dragon
React Summit US 2023React Summit US 2023
23 min
Taming the State Management Dragon
We spend a lot of time discussing which state library we should use, and fair. There are quite a few, from the common one everyone uses and loves to hate on, to that one quirky alternative, to several up and comers. However, discussing which library is best puts the cart before the horse.

When figuring out how to handle state, we should first ask ourselves: what different categories of state do we need? What are the constraints of each category? How do they relate to each other? How do they relate to the outside world? How do we keep them from becoming a giant, brittle ball of yarn? And more.

This might sound overwhelming, but never fear! In this talk, I'll walk you through how to answer these questions, and how craft an approachable, maintainable, and scalable state system. And yes, I will talk about how to pick a state management library too.