The initial gut reaction may be to get wound up about the notion of forking essential tooling. However, yarn works in a way that is compatible with existing infrastructure. It still uses the existing npm registry and its CLI is mostly identical to that of [CODE]npm[/CODE].
The Bugsnag frontend team was on pins and needles to give it a spin, primarily because we have frequently gotten tangled up by dependencies changing between different developers’ machines. We often have to delete our node_modules folder and re-install everything to solve mysterious problems. We’ve tried npm’s shrinkwrap feature before, but, like Facebook, there were issues with it getting out of date so we’ve been itching for an alternative solution for some time.
Yarn solves this problem by using an automatically updated “lockfile” to tie down the dependencies to a specific version. After this file is committed to source control, we should never have to worry about inconsistent dependencies between machines or variations over time.
The migration process was extremely simple. Just run the [CODE]yarn[/CODE] command and commit the resulting [CODE]yarn.lock[/CODE] file. Then grep all our docker and deploy scripts for references to [CODE]npm[/CODE] and replace them with the yarn equivalents.
Some initial rough benchmarks look very promising. Just so you know the wool hasn’t been pulled over your eyes, here are the raw numbers.
Yarn will cache dependencies so subsequent installs can be done without re-downloading. This even works without an internet connection.
Even without caching, Yarn is faster due to parallelization.
I’m especially excited about the impact it will have on the CI server where we start with a freshnode_modules folder for every build.
The API is mostly the same with a few notable exceptions. With NPM the default [CODE]npm install <some-package>[/CODE] command would not add the dependency to [CODE]package.json[/CODE], where as yarn add [CODE]<package-name>[/CODE] will. I think this is preferable as the default behavior since the alternative makes it too easy to forget to commit a dependency change.
Yarn also adds several bonus features. The [CODE]yarn why[/CODE] command, which will show you which of your dependencies is causing a package to be downloaded.
These are only some initial impressions of yarn. There are also many features that I didn’t get to cover. Check out the official site to learn more, including the security enhancements, performance features, and flat mode.