npm vs. Yarn
npm vs. Yarn
In this post we compare two of the most popular package managers around, npm and Yarn. Is there a clear winner? Read on to find out.
Join the DZone community and get the full member experience.Join For Free
Maintain Application Performance with real-time monitoring and instrumentation for any application. Learn More!
Yarn was created in collaboration with developers at Facebook, Google, Exponent, and Tilde to solve a growing set of problems with the npm (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
package.json. A command of
yarn add 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
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.
The Drawbacks of Yarn
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 a 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.
Published at DZone with permission of Stephen Goncher , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.