Yarn versus npm, what's the big deal?
By: +David Herron; Date: Tue Sep 19 2017 17:00:00 GMT-0700 (Pacific Daylight Time)
Let's start by looking at the promises made on the Yarn website -- https://yarnpkg.com/en/
- Ultra Fast - Yarn accomplishes this by caching every package it installs locally.
- Mega Secure - Checksums verify the integrity of packages before installation, and before its code is executed.
- Super Reliable - The
yarn.lockfile records precise exact package versions so that everyone on your team is in lock step and you don't have bugs from version creep.
At the time Yarn was introduced, back in 2016, npm was rather slow. I think the speed factor is the major selling point for Yarn. However the npm team have not taken the competition lightly. Over the last couple years npm's performance has improved.
According to npm,
npm@latest) they've spent the last year and a half making some major improvements to npm. That time-frame predates Yarn's existence (a year-and-a-half before May 2017 is in late 2015), so npm did not make those improvements as a response to Yarn. Maybe.
In any case the high level points of the
npm@5 announcement is: a) It's fast, b) It's consistent (due to a lock file)
npm@5 is now the default with Node.js v8 and beyond. This latest version of npm may be improved enough to warrant ignoring Yarn.
Yarn uses the same
package.json format as used by npm. Yarn doesn't have its own package repository. Instead Yarn gets package information from the npm repository, and when a user publishes a package using Yarn the package is published to the npm package repository.
Yarn is so similar to npm that they've published a migration guide showing the command line options are nearly identical: https://yarnpkg.com/en/docs/migrating-from-npm
Kicking the tires
Installation for me - a Mac OS X user who prefers MacPorts - is:
$ sudo port install yarn Password: Warning: port definitions are more than two weeks old, consider updating them by running 'port selfupdate'. ---> Computing dependencies for yarn ---> Fetching archive for yarn ---> Attempting to fetch yarn-0.24.4_0.darwin_15.noarch.tbz2 from https://packages.macports.org/yarn ---> Attempting to fetch yarn-0.24.4_0.darwin_15.noarch.tbz2.rmd160 from https://packages.macports.org/yarn ---> Installing yarn @0.24.4_0 ---> Activating yarn @0.24.4_0
It installs an old version, Yarn 1.0 has been released. But that might be because my port definitions are more than two weeks old.
I'm also told this:
yarn has the following notes: yarn stores data in: ~/.yarn ~/.yarnrc ~/.cache/yarn ~/.config/yarn Should you choose to install packages globally with yarn (yarn global add), these files will not be removed if you deactivate or uninstall yarn. By default, these packages will be installed in ~/.config/yarn/global, and soft-linked to /opt/local/bin. To uninstall them all: $ ls -1 $HOME/.config/yarn/global/node_modules/ | xargs sudo yarn global remove You may then remove the directories listed above and uninstall yarn. yarn is meant to replace NPM, and may cause conflicts if you use both. You may override the default global installation directory by setting the PREFIX environment variable, e.g. mkdir -p $HOME/.config/yarn/bin # Or wherever you want export PREFIX=$HOME/.config/yarn/bin export PATH=$PREFIX:$PATH
That's easily accomplished with:
$ vi ~/.profile
Followed by starting a new shell, or else running those commands by hand.
I ran this in my home directory expecting to see a USAGE message:
$ yarn yarn install v0.24.4 info No lockfile found. [1/4] 🔍 Resolving packages... [2/4] 🚚 Fetching packages... [3/4] 🔗 Linking dependencies... [4/4] 📃 Building fresh packages... success Saved lockfile. ✨ Done in 0.18s.
But, instead, as you see, it did some installation. Not finding a lockfile it helpfully created a
yarn.lock, and it also created an empty
node_modules directory. Not exactly what I expected since my home directory is not a working project directory. That meant removing those two files to sanitize my home directory.
yarn help is the correct way to get the USAGE message. Sigh.
yarn in an actual project directory:
$ time yarn yarn install v0.24.4 info No lockfile found. warning green-transportation-info: No license field [1/4] 🔍 Resolving packages... [2/4] 🚚 Fetching packages... [3/4] 🔗 Linking dependencies... [4/4] 📃 Building fresh packages... success Saved lockfile. warning Your current version of Yarn is out of date. The latest version is "1.0.2" while you're on "0.24.4". ✨ Done in 29.73s. real 0m30.488s user 0m17.598s sys 0m8.736s
yarn.lock is a YAML file listing precise version numbers as well as URL's from which to retrieve packages. Here's an example from the file:
akasharender@>=0.5, akasharender@>=0.5.14, akasharender@>=0.6: version "0.6.10" resolved "https://registry.yarnpkg.com/akasharender/-/akasharender-0.6.10.tgz#85e87d47e01fe9a471efc3e7975696fabf49c741" dependencies: asciidoctor.js "1.5.6-preview.2" async "^1.5.2" cmnd "0.0.6" co "*" debug "^2.2.0" ejs "^2.4.1" flat-cache "^1.2.2" fs-extra ">=4.0.1" globfs ">=0.2" gray-matter "^2.x" less ">=2.7" markdown-it "^5.1.0" oembetter "*" rss "^1.2.1"
It's interesting that the package URL is via
registry.yarnpkg.com. It would appear the Yarn team maintains a mirror of the main npm repository.
$ time npm install ... lots of output real 0m54.560s user 0m31.978s sys 0m9.448s $ npm -v 3.10.10 $ which npm /Users/david/.nvm/versions/node/v6.11.2/bin/npm
Hm, that's quite a bit slower. This is an out-of-date version of Yarn versus an out-of-date version of npm, and npm was twice as slow (approximately).
Updating to the latest npm is (because I'm using nvm to manage Node.js versions) this simple:
$ nvm install 8 v8.5.0 is already installed. Now using node v8.5.0 (npm v5.3.0)
Then rerun the test
$ rm -rf node_modules/ $ time npm install ... lots of output added 402 packages in 359.632s real 6m0.999s user 0m25.469s sys 0m9.469s
Um, really? Now it's 18x slower. There is a new file,
package-lock.json, that is in JSON format and whose format is rather similar to the
There's also a new directory containing a bunch of packages:
$ ls -ld ~/.npm drwxr-xr-x 1794 david staff 60996 Sep 21 15:20 /Users/david/.npm
So let's re-run the test to see if the local cache will speed things up.
$ rm -rf node_modules/ $ time npm install ... lots of output added 402 packages in 24.33s real 0m25.170s user 0m15.065s sys 0m5.630s
Yup, that performance is on-par with Yarn's performance.
I see no compelling reason to switch to Yarn. Bottom line is that Yarn's primary purpose for existence was to be faster than npm, and npm has improved their performance considerably. I don't see any feature of Yarn that screams to me that I must use Yarn.
When Yarn was announced, the npm team responded by welcoming the competition. You'd think that since Yarn is piggybacking off the hard work npm, Inc. performs to set up and maintain and monitor and police the npm Registry, that npm, Inc. would be upset. You could see Yarn as a freeloader organization. But that would be to misunderstand the ethos of the open source ecosystem.
Instead, npm, Inc., took this as a challenge and took it upon themselves to improve their product. As a result npm is much better than it had been.