Yarn 2.4 🎄🎁 Log Filters, Audits, Better Warnings, ...

Hey everyone! It's this time of the year where everyone is slowly preparing for the holidays. This year will probably be slightly different, but I can't wait to at least take a well deserved time off. But before that, let's talk about our next minor Yarn release, and a little bit about the next-next release: Yarn 3!

Oh, and in case you missed our previous release notes, you can find them all here in all their glorious emojiness: 👇

Plugins

We'll try to reference external plugins made by our community in our release notes, so if you made one that you want to share, please ping us! We're also looking at adding a page on our website to list them all, improving discoverability 💫

For now, let me present those two:

yarn.build by ojkelly is a fast monorepo builder for Yarn. In a sense it's similar to yarn workspaces foreach but more opinionated, and thus easier to adapt to existing workflows. It parallelises builds, shows what's being executed, and generates zipped archives suitable for AWS and similar platforms.
prod-install by Larry1123 and NETSVS is a much more powerful version of yarn workspaces focus that copies the selected workspaces into a target location before transforming it to become self-sufficient - the final directory thus being ready to be efficiently cached and deployed via Docker layers.

Audits

Both Yarn 1 and npm had this handy little feature called audit. Originally developed by npm when they acquired Lift, this command lets you quickly check whether some of your dependencies have known vulnerabilities, which may come in handy in some types of application. Unfortunately, since the audit endpoint isn't documented, its implementation wasn't entirely obvious.

Thanks to our contributors, Yarn 2.4 now includes proper audit, available via the yarn npm audit command! And to make up for the delay, we've implemented various interesting ways to run it, under the form of the -A,--all and -R,--recursive options - check the examples for details!

We've also significantly improved the output to be more in line with the rest of the CLI, providing information in a more compact way:

This new output is compatible with the --json flag, meaning that you can leverage the information obtained from yarn npm audit --json from any script you want - even the command-line itself, using tools like jq!

Better Warnings

Peer dependencies have always been a difficult concept to grasp. They are not that hard per se (a peer dependency is always satisfied by the exact package instance used by the parent of the package listing it), but various other factors played into it and caused typical installs to produce many rarely actionable warnings.

No more!, do we say. Starting from 2.4, you can expect the warnings produced by Yarn to become vastly better than what we used to report. For this first release with warnings being a focus, we've implemented a new range merging algorithm that lets us drastically decrease the amount of warnings we emit. The idea is simple: imaging the following dependency tree:

.
└── your project/
    ├── @storybook/react/
    │   ├── (peer) react@^15
    │   ├── storybook-plugin-foo/
    │   │   └── (peer) react@^15
    │   └── storybook-plugin-bar/
    │       └── (peer) react@^15
    └── react@17

Before, these are the warnings you'd have had:

your project provides react@17 to @storybook/react, which isn't compatible with react@^15
your project provides react@17 to storybook-plugin-foo, which isn't compatible with react@^15
your project provides react@17 to storybook-plugin-bar, which isn't compatible with react@^15

From all those warnings, only one was truly actionable: the @storybook/react one. The two others were mere byproducts from the first, and were just making the output harder to read. This is now fixed, and Yarn will instead report:

your project provides react@17 (pXYZ), which doesn't satisfy what @storybook-react and its dependents request

The pXYZ is a hash that you can use with a new command, yarn explain peer-requirements <hash>, to get the exact list of packages that contribute to the final peer dependency requirement, and whether they are met or not. For instance, this is what I get in one of my projects:

Log Filters

Even if warnings will get smarter, there's always this one case where you really don't care about a specific message. For instance the message saying that a package wasn't in the cache is sometimes controversial, with half of our users liking it, and the other half wanting to hide it.

While you could use preferAggregateCacheInfo to tweak that, it's only about one message. What about others? Well, starting from 2.4 we introduce a new setting called logFilters. It has the following syntax:

logFilters:
  - code: YN0005
    level: discard

With this configuration, all messages matching the specified code (which would be builds being disabled, per our documentation) will be removed from the output. And if you need to only remove a single line, it's possible as well:

logFilters:
  - text: "core-js@npm:2.6.11 lists build scripts, but its build has been explicitly disabled through configuration."
    level: discard

We hope this feature will let you tune your package managers to watch what you truly care about, which can be different from one person to the other.

And also

As always, these release notes focus exclusively on the big-picture stuff - as always, there's a lot more things that have been improved under the hood. Check our changelog for a comprehensive list, but we can mention:

Updated our patches to account for TS 4.1 and FSEvents 2.1.2
Improved usability when using the global cache
Improved usability in the VSCode ZipFS extension
Improved performances on recurrent installs
Improved Windows compatibility when running binaries
Improved the display for yarn upgrade-interactive
Fixed the postinstall scripts run by yarn workspaces focus
Fixed some edge cases with || and interpolation errors
Added support for proxy settings (caFilePath, ...)
... and more!

What about Yarn 3?

This is a big news for us! Yarn 2.4 is expected to be the last minor release for the 2.x line! After a year of development, we now have put aside enough items to be worth addressing in a new major.

While the 3.x branch will be much less disruptive than the jump from 1.x to 2.x (after all we won't need to rewrite the whole codebase this time! 😁), it'll include a few breaking changes. Most of those are listed here but, as you'll see, they are mostly about old workflows being deprecated, and are unlikely to affect most codebases.

One important note though: given that Node 10 will reach its end-of-life in April, it's likely that Yarn 3 will be Node 12+ only. So if you want to prepare for it, start considering upgrading to either Node 12 or, better yet, 14!

Blog