— Yarn (@yarnpkg) October 11, 2016
In comparison to
npm, the Yarn website pushes these three main benefits forwards:
Not in that list, and something that I’m really super excited about, is the fact that Yarn is architected in such a way that it basically is a drop-in replacement for
- You don’t need to learn an entirely new (*) syntax (unlike the switch from grunt to gulp to webpack).
- You don’t need to find your packages on a different repository/website (unlike the switch from bower to npm).
- You don’t need to change your directory structure (Yarn still uses
package.jsonand puts everything in the
For us, the end user, not much changes. Everything that was, still is. From a UX perspective that can count.
Working with Yarn: “It’s a Unix System, I know this!”
(*) I know. The syntax is a tad different, but not that much: Once yarn is installed, just run
yarn install) instead of
npm install. To add a package to your
yarn add packagename (instead of
npm i packagename --save). Slightly different indeed, but nothing big.
Of course I’m also excited about the initial benefits listed. Take reliability for example. Coming from a PHP background – where we have Composer for dependency management – I applaud the fact that Yarn – like Composer – automatically generates lock files.
Yarn Review so far:
👉 It's Super Fast. Like woah.
👉 Creates package.json if one doesn't exist
👉 Saves Exact versions in a .lock file
— Wes Bos (@wesbos) October 11, 2016
Thanks to the
yarn.lock file you can no longer end up with different versions of dependencies on different machines should a new version of a dependency be released in between two runs of
yarn install. The lock file, as its name indicates, locks the dependencies down to exact versions (cfr.
npm shrinkwrap, but then by default and on steroids). That way you have reproducible installs, on all machines.
The magic clue behind it? Whenever you run
yarn install, the
yarn.lock file has precedence over the
- If the
yarn.lockfile exists, the (exact) versions defined in it will be used.
- If no
yarn.lockexists, the (loosely defined) versions defined in
package.jsonwill be used, and a
That way you, as a developer, have true control over which exact versions will be installed on every machine. As long as you commit your
yarn.lock file into Git (or whatever VCS floats your boat) of course.
Let me rephrase and repeat that for you, as it’s really important: you must commit the
yarn.lock file into Git.
To update the versions locked in the
yarn.lock file run
yarn upgrade. After having verified that your project Works On My Machine™, it’s safe to commit the updated lock file into Git.
Oh, and about the aforementioned speed benefit (thanks to parallelization and the use of a global cache on disk), let this tweet convince you:
NPM install: 2m23s, Yarn first install: 40s, yarn second install: 18s 🚀
— Sebastian【ツ】 (@sebdedeyne) October 11, 2016
So, what are you waiting for?
This post has also been cross-posted to Medium. If you like it, feel free to give it a <3 on there.