Trying to solve the dependency management problem by adding another layer of dependencies to the equation is as stupid as it sounds.
From an outsider that doesn’t do web development for a living, this is crazy. I don’t know how people cope with the web ecosystem. Specially the front-end part.
Despite what NPM said on its blog, Yarn isn’t merely a “backwards-compatible client for the npm registry.” In reality, Facebook launched a direct competitor to NPM but made it easily compatible so developers could migrate from NPM to Yarn with minimal effort. One of the ways Facebook did this was by adding Yarn to the NPM registry. NPM saw the writing on the wall but wrote a PR piece to sugar coat it.1 If you’re using NPM and you want to switch to Yarn, you can switch by installing Yarn via NPM, and then you can completely ditch NPM. It’s important to note that there are a myriad of ways to install Yarn, however, and you don’t need NPM at all in order to install or use Yarn.
Why would you want to use Yarn over NPM? Maybe because it’s more performant. Or maybe because you want to micro manage the versions of your dependencies’ dependencies, but you don’t like to use npm-shrinkwrap because of how long it takes to fix major bugs with it, or because of how it doesn’t play well with private repositories as dependencies. Or maybe you just like new shiny tools, especially ones that are built to solve pain points by a company of Facebook’s calibre.
Regardless, Yarn is a great tool, it’s a serious competitor to NPM, and it’s here to stay.
- Saying that Yarn is in the same camp as
npm-installis a stretch. Using NPM to install Yarn is like using an Android to visit Apple.com and order an iPhone. Don’t get confused by the fact that one facilitates the other by allowing it to be on its registry. They’re not friends. ↩︎