Late last year, a new package management system for Javascript was introduced known as Yarn, designed to replace the deficiencies found in npm. Yarn has been showing up on Twitter and StackOverflow answers, but it isn’t always clear what the benefits and tradeoffs are, which is what this post aims to clear up.
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.
Drawbacks
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.
One other concern of Yarn is that it’s a new framework, which can make some people uncomfortable, though this is ironic given how there seems to be a new Javascript framework developed every six hours. Where mature tools are a priority, Yarn may not be the best for a stable experience, as with new tools, there’s always a role of the dice. With that said, we’ve been using it in our production pipeline for a couple of months without issue. Developers who benefited from Yarn being added to their pipeline have since started using Yarn locally for their work to replace npm and are quite satisfied with the results.
Conclusion
Yarn has a number of improvements over npm, whether it’s faster processing, more security, or better dependency management. It may be young compared to npm, but it’s quickly gaining traction in the Javascript world, and for good reason. Using Yarn in your pipeline can help alleviate a number of headaches and add excellent refinements to your Javascript package management. Yarn is a worthy successor and replacement for npm, and we are looking forward to its continued advancement.
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.
|
Stelligent Amazon Pollycast
 |
