---
slug: release/3.2
title: "Release: Yarn 3.2 🚢🔮"
authors: [arcanis]
---

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](https://github.com/yarnpkg/berry/blob/master/CHANGELOG.md) is much more comprehensive.

{/* truncate */}

## Sponsoring

The Yarn org needs your help to make our work more sustainable! Please take a look at our [OpenCollective](https://opencollective.com/yarnpkg) and [GitHub Sponsors](https://github.com/sponsors/yarnpkg) 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](https://musl.libc.org/) 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](https://yarnpkg.com/advanced/error-codes), 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:

![Explain Output](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/brt0umb2jvfkkjeu2kv9.png)

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`](https://yarnpkg.com/cli/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.<br/><br/>

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

![Improved Git Error](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/m4zkw674viqnuqc7c8fr.png)

## 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](https://github.com/yarnpkg/berry/issues/3591) 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<br/><br/>

- We'll be exploring a new resolution algorithm that will prevent most of the attacks similar to the recent [`color.js` hijacking](https://news.ycombinator.com/item?id=29851065).<br/><br/>

- 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.

  <br/><br/>

- 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.
