Yarn 3.2 🚢🔮 Libc, Yarn Explain, Next Major, ...

Welcome to the release notes for Yarn 3.2! This release is a little smaller than the 3.0 and 3.1, as we've hold off on some changes in preparation for our next major ... but more on that later 😃

As always, keep in mind those are only the highlights, the full changelog is much more comprehensive. And if you just happen to love reading our release posts, here are the past entries 👇

• Yarn 3.1 🎃👻 Corepack, ESM, pnpm, Optional Packages ...
• Yarn 3.0 🚀🤖 Performances, ESBuild, Better Patches, ...
• Yarn 2.4 🎄🎁 Log Filters, Audits, Better Warnings, ...
• Yarn 2.3 🍦✨ Info Command, Detailed Options, Nohoist, ...
• Yarn 2.2 🚅🌟 Dedupe, Faster, Lighter, ...
• Yarn 2.1 🐱‍🏍 Git Workspaces, Focused Installs, Loose Mode, ...

Sponsoring

The Yarn org needs your help to make our work more sustainable! Please take a look at our OpenCollective and GitHub Sponsors pages for more details 😊

Libc Field

We implemented in 3.1 a feature we call "conditional dependencies". The idea is simple: if a package is listed in the optionalDependencies field and its os / cpu fields don't match the current machine, we don't install them at all. This pattern is today used by various tools like Esbuild or SWC to avoid overfetching dependencies that systems wouldn't needed.

One problem however is that while os and cpu are useful at differentiating systems, they aren't the only parameters at play. In particular, knowing the standard C library against which native modules are built is critical: using a module linked against the glibc with a Node release built against musl would promptly crash.

To avoid this, Yarn now supports a libc array field in the package.json that currently accepts any of two values: glibc and musl. Just like os and cpu, packages will be skipped if they don't match the host libc.

This isn't the final iteration; while libc is a good improvement, more parameters could be taken into account. Both Yarn and npm have open proposals to address this situation, and we'll see what we decide to implement.

New Command: yarn explain

It can be difficult to know how to react when facing errors. Our website tries to help with that by providing detailed explanations, but when you're in your terminal this might not be the first thing you have in mind.

The new yarn explain command will let you get all the details about an error, right from your terminal:

In the future we'll expand the documentation to cover more error messages, and may use yarn explain to aggregate some of the other similar mechanisms we already have (such as yarn explain peer-requirements).

UI Improvements

Every version we look for little UI annoyances to fix. This time is no exception with a couple of neat improvements:

• The resolution step will now have a spinning wheel; we can't show a percent-based progress since we don't know how many packages we'll have to resolve until the end, but a spinner will at least let you know the process isn't stuck.
  
  

• Errors thrown when cloning Git repositories were previously reported as regular stack traces. They will now have dedicated output.

Next Major

With 3.2 out of the door, we'll now start working on the next major release: Yarn 4! We have an issue highlighting the things we currently have in mind, but generally speaking expect us to decrease the friction when starting new projects. Some highlights:

• We'll drop support for Node 12, as it will reach EOL in April
  
  

• We'll be exploring a new resolution algorithm that will prevent most of the attacks similar to the recent color.js hijacking.
  
  

• More commands will be integrated with Git; we used to refrain from doing so due to some related projects using Mercurial, but this isn't the case anymore. Projects not using Git will still be able to use Yarn, but some features may not be available there.

  • To give you an idea of the kind of integration we have in mind, the yarn stage command (already available as a plugin) allows to automatically commit all dependency-related changes without impacting any other.

• The official plugins will be shipped by default, to reduce the friction. In practice the Yarn binary is very small, so we have some leeway to bundle everything together so that you don't have to download more subparts.

  • Even if bundled by default they'll technically remain plugins, so it doesn't change anything for third-party plugin authors: our plugin API will remain a focus for us, and will keep improve.

And more! 🙂 We have plenty of other ideas to improve Yarn, so expect to see a significant amount of improvements in our next major - including lower friction when starting new projects or migrating older ones.