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: 👇
- Yarn 2.3 🍦✨ Info Command, Detailed Options, Nohoist, ...
- Yarn 2.2 🚅🌟 Dedupe, Faster, Lighter, ...
- Yarn 2.1 🐱🏍 Git Workspaces, Focused Installs, Loose Mode, ...
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 foreachbut 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 focusthat 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.
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
-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!
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
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:
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.
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
- Fixed the
postinstallscripts run by
yarn workspaces focus
- Fixed some edge cases with
||and interpolation errors
- Added support for proxy settings (
- ... and more!
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!