Yarn: Yet Another … Package Manager

Yesterday, Facebook not only unveiled Workplace, but they also open sourced Yarn, a new dependency manager for JavaScript.

Yarn was built by Facebook, Exponent, Google, and Tilde, and is designed to replace both npm, the Node.js package manager, and Bower. According to Facebook, Yarn is fast, reliable and secure—three important characteristics npm is lacking.

The news quickly gave the web-tech world a good shaking, and also led to something like this:

It's been 11 minutes since yarn came out and I just got a call from a recruiter looking to hire a dev with strong yarn skills.

— Wes Bos (@wesbos) October 11, 2016

A Superior npm Client

Having Yarn integrated into your workflow, you still use the npm registry, and thus the same packages that your project depends on. What changed, however, is the way these dependencies are being resolved, served and persisted.

Deterministical Dependency Installation

When using the npm client, a project’s dependencies are usually defined in a package.json file. Just like the composer.json file when using Composer to manage your dependencies in PHP projects, the package.json file lists all depended-upon packages, each with a specified version. These specifications follow Semantic Versioning, and may either target a concrete version (e.g., 1.2.3), or a version range (e.g., 1.2.*, or >=1.2).

When using the npm client to install your dependencies, first the information in your package.json file is being read, and then the actual packages will get fetched off the npm registry and finally copied into your project’s node_modules folder. This is done in a non-deterministical way, though, which means that doing this will not always produce the same results. This again might lead to different people having different files, even though they used the exact same package.json file. This is something that you really would want to avoid.

Yarn, on the other hand, uses a deterministic algorithm to install your dependencies. And furthermore, similar to Composer’s composer.lock file, Yarn creates a a lockfile, yarn.lock, filled with detailed information on the exact nature of all installed dependencies. This results in the exact same files listed in the lockfile, irrelevant of who triggered the install, and what was stored in the node_modules folder before, if anything.

Caching Downloaded Packages

Every single time Yarn actually downloaded a required package, it gets stored in a global cache. For subsequent requests for this exact dependency, Yarn will simply fetch it off the global cache, and not bother (unnecessarily) downloading it again. This way, not only is installing/updating dependencies sped up by an order of magnitude, but also does the global cache allow for working offline—as long as what you are looking for can be found in the cache, of course.

Getting Started

If you want to transition to (or test) Yarn, all you have to do is install and use it:

$ npm i yarn -g

( I really can’t help, but to me this looks like digging one’s own grave… 🙂 )

Since Yarn just goes ahead and reads the package.json file that you already have, you now only have to internalize the new commands as well as the available options.

Adding Dependencies

With Yarn, to define one package as a dependency of your package, and thus add it to your package.json file, you just do this:

$ yarn add <package> [options]

Basically, this is the replacement for the npm command $ npm install <package>.

If you want to install a package for development only, you just go ahead and use the --dev flag, like so:

$ yarn add <package> --dev

Installing Dependencies

The npm command $ npm install for installing all depended-upon packages is replaced by the following:

$ yarn [options]

Actually, this is a short-hand for $ yarn install, so all the options you provide will get passed to Yarn’s install command.

By default, this will install all development dependencies. If you only want to install the packages needed for production, you just use the --production flag, like so:

$ yarn --production

 Updating Dependencies

Fetching the latest version for all of your packages, while still respecting the individually defined version constraints, is done like so:

$ yarn upgrade

This is the replacement for $ npm update that you are used to from working with npm.

Updating Yarn

Just like Composer, Yarn is able to update itself with a single command:

$ yarn self-update

What Now?

Yarn was released (into the world) not more than a day ago, and yet it went viral in no time, got covered in all sorts of media to various degrees, and its GitHub repository has been starred almost ten thousand times.

So far, I only half-heartedly experimented with it, but I already planned a follow-up post on Yarn including first real-world tests, similar to what Facebook did theirselves. I’m more than curious as to whether I will be able to prove Yarn’s superiority, or not.

And you? Did you know about Yarn? Did you use it already? Are you even an expert? If so, ask Wes. Maybe he will contact that recruiter on your behalf…? 🙂