I got the inspiration for this post from grazing the surface of dependency management. And by grazing the surface I mean learning that it exists.
I realized that before I can write something on dependency management, I should probably learn more about the package manager that I use every day at work: yarn.
Before doing any research, all I knew was that yarn fetches libraries, adds them to your project, and keeps a lock file to keep track of those additions as well as the version numbers. I learned from my manager that it was created because of significant pitfalls in the monopoly of package management back in the day: npm. Because I thought a package manager’s job was super simple, I became curious about what those pitfalls were and how yarn solved them. In other words, there had to be more to yarn than what meets the eye.
Where do I Phind the Answer?
I recently discovered this AI tool that’s been very helpful for all things development: phind. Whenever I’m wondering how to approach a programming problem, I throw the question into phind and it’ll either answer it outright or give me a bunch of links to go deeper and find it myself.
The first thing I learned from a simple, “What is yarn and what does it do?”, was that it stands for Yet Another Resource Negotiator. I’ve actually always wondered where that name came from but for some reason didn’t look it up. Considering the prevalence of cats in developer culture, I just figured the creator(s) had a cat that loved playing with yarn.
The handful of paragraphs in phind’s answer didn’t answer my question of what yarn brought to the table that npm didn’t. So it was time to dive deeper.
And what do you know, the second link after the yarn docs in phind’s response was titled Yarn vs npm: Everything You Need to Know. Seemed like a great place to start.
History Lesson
Until 2010, when npm was created, developers downloaded and managed packages themselves (makes me pretty grateful to have started coding almost a decade after that). Sitepoint goes as far as to say that “npm was the magic wand that pushed the Web to the next level.” Sounds a bit dramatic. But when you think about it, the ability to share solutions to problems with a simple yarn add must have exponentially accelerated technological growth.
Yarn was created by Facebook in 2016 as an alternative to npm. It looks like the biggest npm drawback it addressed was the lock file. With a yarn.lock, sharing repos went from a hassle to nearly trivial.
Not only did yarn fill a huge gap in npm’s product, but they also improved upon existing features such as performance and security. Basically, yarn was an all-around better package manager.
And the npm team was very aware of this. They released npm 5 just a year later in 2017 with npm’s lock file: package-lock.json. Then, another year later, they released npm 6 addressing the security disparity by checking vulnerabilities before adding deps.
It’s safe to say by that point they were pretty much on level playing ground.
Decision Time
As is the case with most tool selection decisions in software, the answer seems to be it depends on the project you’re working on. I’ve always found this to be a cop out. If I’m reading an article and it goes through all the pros and cons, I’d prefer there to be a decision at the end rather than, “You’ll need to look at your project requirements and decide for yourself.”
I can confidently say that from reading a handful of articles and looking at documentation, yarn is the way to go. It sure doesn’t win this competition by a lot. But I believe it’s the better manager because of the speed advantage, less memory usage, built-in offline support, and a way cooler name.
It’s a similar competition to Apple vs Google Maps (yes Waze is better but it uses too much battery). I’m the biggest advocate for Google Maps. It’s not better by much, but Apple has steered me wrong two more times than Google, which never has. There’s something about software that makes people, especially non-technical users, super angry when it doesn’t do exactly what they expect. So one wrong turn is really all it takes to get someone to make the switch.
An analogous scenario I’m picturing in the package management comp is yarn’s offline mirror. Imagine you need to download moment for your npm configured project and your internet cuts out…and your phone is out of hotspot data. You’d be completely blocked. But if you had instead used yarn, moment would be cached for download without any connection. In a race this close, it’s the small things.
So if you’re deciding, go with yarn until it steers you wrong, which I’d bet will never happen.