Knitting Your Web Code Together in a New Way: Why I Started Using Yarn

A while back I was reading posts about the top development tools of 2016 and what to watch out for in 2017, and both of them mentioned Yarn Package Manager. I hadn’t heard of it so I read a bit more into it and it sounded very interesting.

A couple months later I was getting ready to start on a new ASP MVC website. I was always bothered by the fact that we check all of the code for the different JavaScript libraries that we reference in to our source control. For example, updating from Bootstrap 3.3.1 to 3.3.6 would cause dozens of files to get updated and when a Pull Request is created there are a bunch of files that we don’t own getting pulled in as changes and cluttering up the review.

I thought I would solve it by using Bower since Microsoft had added support for it in Visual Studio 2015. When I went to the Bower (http://bower.io) site, I was greeted with the following message:

This prompted me to jump in with trying out Yarn and I found the experience to be super easy. It didn’t take much to install a plugin for our build process for VSTS and set up the new task to restore the packages before doing the .NET build.

The best thing about going to Yarn is that it uses the same packages.json file that npm uses so if you have people or build processes that don’t have access to Yarn, they can still use npm to restore their packages.

There are two aspects of Yarn that make me prefer it over npm:

• The amount of time it takes to restore packages after the first time you have downloaded a package is very short. Yarn caches the packages and its dependencies so the first time you do a Yarn install it may take 20 seconds to run but the next time it only takes a half a second while npm will take 20 seconds to run every time.
• A yarn.lock file is created to give hints to other developers as to the versions of packages that were used when the package.json file was last updated. This is nice because I was recently going through a tutorial that used npm to manage the packages. The code base that I started with would not build out of the box because several packages had been updated and the newer versions of these packages caused build errors. If I had known the exact version the developer had used when building the tutorial, I could have used those versions and moved forward with the tutorial. But as it was, I was stuck.

I am hopeful that we can start transitioning more of our team to Yarn instead of npm as it will not break any current workflows. This should be easy since you can have some team members use Yarn while others use npm until they see the benefits of switching.

If you are currently using Yarn, I would love to hear what your biggest obstacles (technological or organizational) have been to overcome and what are the biggest gains you have seen.