When the yarn package manager was released, I was one of the holdouts that stuck with npm for a long time. Originally, I thought the npm team felt like the perfect underdog story with a solid, diverse team. I didn’t see the reason to switch to “yet another Facebook project”.
I did really appreciate the fire it lit under npm’s bottom though. The npm CLI shipping definitely got much quicker for a while after yarn’s release.
In addition to being yet another Facebook project, I was reluctant to change because there were certain things that I wasn’t keen on.
npm being a VC funded company that was shipped as part of node was always precarious. It became even more so when innovation stagnated and it became apparent it was no longer a “nice people matter” type of company.
So, I somehow, began to trust Facebook more (WTF?).
However, after many years building packages in the node ecosystem, I began to find it tiresome to manage many packages amongst many repos. There’s often an obvious boundary for packages though their development is interrelated.
This was around the time the monorepo began to gain a lot of popularity in open source.
After some experimentation, that’s when I fell in love with the workspace. yarn nailed this.
As soon as the yarn workspace became an integral part of my workflow I couldn’t look back. Not to mention, having to remember two different CLIs based on whether I was working with a workspace or not was too much overhead.
This really boils down to two reasons. First, when I needed to debug two libraries together, I began using the yarn workspace workflow. I’d often clone both projects into a single project and then create a “consuming” package which I interlinked as a yarn workspace.
This was super powerful.
The other reason that really solidified yarn for me was working with Gatsby Themes. It ultimately made the most sense for the theme author workflow to use yarn workspaces since they’d have to manage one or more packages in addition to a consuming starter.
One other motivation was the fact that yarn-based projects
simply worked better with yarn. A handful of large frameworks
and libraries would work with
yarn install but wouldn’t
npm install. This was a frustration with my workflow
and it helped me gradually gain trust in yarn.
So, I caved. Over time some key features became to powerful of a gravitational pull:
I’m all in on yarn these days. What won me over was the yarn workspace. I stuck around for speed, caching, and the yarn.lock.