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:
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.,
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.
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.
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
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
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
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.
Just like Composer, Yarn is able to update itself with a single command:
$ yarn self-update
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…? 🙂