Alex Periel , CBDO
The year has just begun and, already, it’s rocked by a pleasant surprise - the launch of Yarn 2, a new and updated version of a package manager that’s been the golden standard for 4 years now. Released on the anniversary of the day it was announced, it’s an improvement on all fronts and it’s going to be the manager of choice from now on.
You might be wondering what makes Yarn 2 so good or maybe even what Yarn is. This is why this article is here for you: an explanation of Yarn, a comparison of it to other package managers, and an exclusive view from inside, featuring the perspective of SysGears, one of the core contributors to Yarn 2.
The History of Yarn 1
To understand why Yarn was created, you need to know what a package manager is and why npm, the most ubiquitous tool of this kind, wasn’t up to snuff. Package managing applications are used to download and connect various pieces of code and manage their dependencies on each other. It makes engineers’ lives easier as they don’t have to rewrite things that someone’s done before and automatizes the routine parts of writing code.
Yarn 1 joined the ranks of package managers in 2016, made by engineers from Facebook, Google, and Exponent as a direct response to their own problems with npm. They needed something faster, more secure, and consistent. When a bunch of talented engineers needs something, they build it.
At first, they attempted to just add functionality to npm itself but that proved both challenging and counterproductive. The tool scaled poorly and resisted all attempts to mold it for environments with continuous integration. So Yarn 1 was created as a standalone, intended to be superior to npm and other package managers in all the ways that matter.
Yarn 1’s first priority was improved performance with only a handful of features that distinguished it from npm. But this is one of those cases where quality wins over quantity. It had a very minimalistic CLI output, an ability to restrict module licenses, and, most crucially, compatibility with npm and bower. The latter meant it was easier to transition your workflow to this new tool, which made onboarding easier and helped Yarn 1 gain widespread acclaim.
Most common problems with Yarn 1 and competition with new npm versions
We’re not going to pretend that Yarn 1 was flawless and that npm took this new competitor calmly. So this is a prime opportunity to compare Yarn 1 with npm’s later development and see which issues were present in both tools.
- The way they structure information. They use the node_modules method, which is impractical and overly complex with structures that could easily be simplified. In fact, that’s exactly what a method called PnP accomplishes and it’s been one of the main requests for both managers and one of the core promises for Yarn 2.
- Despite improving performance, npm couldn’t really compete in terms of features. For example, it still lacks the workspace option to this day, which makes life easier for engineers on sprawling projects.
- Unnecessary rebuilding. Yarn 1 had this issue where executing a command like yarn remove would rebuild every single package in the dependency tree. That won’t be happening any longer as Yarn 2 only rebuilds packages when the tree they depend on is changed.
Introducing Yarn 2 and the role of SysGears in this
So, time to talk about the main event - Yarn 2! If you follow the main Yarn maintainer Maël on Twitter, you know that the project was first announced exactly a year ago. As SysGears constantly used Yarn in its own project — Open Source toolkit AUSK, the team knew the product’s inner workings and all of its problems. This is when we decided to help make Yarn 2. This year between announcement and release has been full of work for the Yarn team with SysGears lending a helping hand to the project.
I’ll give one of the team members a chance to speak for our experts:
Our input on the project consisted of making Yarn 2 easier to transition to. I know that plenty of people requested PnP but its lack of compatibility with React Native posed a problem for some people, a few of our engineers included. Instead of making all those people remain on Yarn 1, we’ve made sure you can transition to Yarn 2 comfortably. The new evolution of Yarn still supports the node_modules method although we’re still working on this functionality and it’s ‘experimental’ for now.
Your core takeaway from that depends on which language you use but it’s either:
- Finally, PnP!
- I’ll stick with node_modules.
Those are both great but they’re far from the only things you should be excited about in Yarn 2.
- Improved output readability.
- CLI that’s more flexible for workspaces. You can now choose between adding a package that’s the same as in your other workspaces or upgrades a package in all workplaces, no need to go back and check which version is used where.
- A beta functionality called version. To put it simply, it lets you delegate part of the release duties to your contributors without worrying that your whole structure gets messed up.
- yarn dlx, which downloads and executes a script. It’s like a more secure version of npx that doesn’t leave any gaps in the fence for an attacker to sneak through.
- patch: a protocol used to apply changes to one specific package in your directory. It also uses checksums and caching, so it works fast and error-free.
At this point, you may be thinking, wow, this list is getting long. Thankfully, Yarn 2 offers plenty more new features. Visit GitHub and get yourself started with this new take on package managers.
And if you’re looking for a team that stays up to date on modern technologies, helps them grow and evolve, and knows when to start using a new tool for maximum efficiency, well, you’ve come to the right place. Let’s catch up on a call and talk about what kind of opportunities you have to work with up-to-date technologies and skilled tech experts, contact us at firstname.lastname@example.org to get started.