Stelligent Amazon Pollycast
Yarn was created in collaboration by developers at Facebook, Google, Exponent, and Tilde, in order to solve a growing set of problems with the npm (or node package manager) client. The biggest of these issues included speed, reliability, and security, which are the hallmarks of good programming practices, let alone devops.
The Benefits of Yarn
Yarn is able to help improve processes in several key ways. The first of these is by far the most intriguing: speed improvement. One particular npm install on my recent projects could take three and a half minutes to complete, nothing earth-shattering, until Yarn shows what it can do. After setting up and running yarn install, the call dropped down to under a minute!
One benchmark found Yarn to be two to three times faster than npm, and it was just as fast, if not faster, running on a non-clean build. On larger scale projects, this can mean the difference between acceptable build times for a pipeline step versus build times slowly getting longer and longer (we are always trying to achieve fast feedback!) Why is it so much faster? The answer lies in parallel installations. While npm will not install the next package until all its dependencies are installed, Yarn will install several packages simultaneously.
Yarn also has better versioning control of packages, with the use of a yarn.lock file, which is similar to a Gemfile.lock file in Ruby. While the package.json file can define a range of module versions, Yarn’s lock file can ensure the same package is installed on all devices. The lock file is created or updated as needed when a new module is added. npm does have its own solution to this problem in shrinkwrap, however, the shrinkwrap file is not generated automatically and must be maintained by developers to ensure it stays up to date. Yarn’s lock file system does all of that automatically by default, making shrinkwrap an unnecessary process and one less file to maintain.
On the security front, npm will run code from dependencies automatically and allow packages to be added on the fly, but Yarn only installs from yarn.lock or package.json. A command of yarn add will install the package and its dependencies much like npm install would do, but, Yarn will also add this package to the package.json file as a dependency, where npm would need a –save flag.
Another great feature involves Yarn only reaching out to the internet to install packages it does not already have, leaving previously installed packages to be read from the .yarn-cache file, saving even more cycle time. Yarn is also non-verbose by default, whereas npm will always be overly verbose; Yarn can be made to be verbose, but its output is still far cleaner and easier to read than npm.
While Yarn offers some great benefits, it’s not quite flawless. The first important issue to notice is that Yarn uses a different registry than npm. This may at first be cause for alarm, but the registry chosen can be changed and is not necessarily less reliable than npm. A best practice is having npm and Yarn be pointed at a different registry than the default, helping to create a reliable Continuous Delivery pipeline using your own repository.
Let us know if you have any comments or questions @stelligent
Stelligent is hiring! Do you enjoy working on complex problems like figuring out ways to automate all the things as part of a deployment pipeline? Do you believe in the “one-button everything” mantra? If your skills and interests lie at the intersection of DevOps automation and the AWS cloud, check out the careers page on our website.