As an outsider to the JS world, can someone give me the quick pros and cons between yarn and npm? Can you switch back and forth in the same project? Is the end result of your package structure the same?
The end result is essentially the same, yes - all directly requested dependencies, and all of their transitive dependencies, are extracted and installed on disk into `./node_modules`.
Yarn came out at a time when NPM was particularly slow and buggy. NPM has caught up some since then, but I _personally_ still like Yarn better. I find the CLI output more useful, and it feels like it installs in a more consistent amount of time.
You should only have one of them in use in a project at time.
PNPM is another alternative package manager that installs the same packages, but tries to use symlinks to a single globally-cached copy of each package to save disk space. (I believe recent versions of Yarn have an equivalent option, but it's not on by default.)
> The end result is essentially the same, yes - all directly requested dependencies, and all of their transitive dependencies, are extracted and installed on disk into `./node_modules`.
Well, no. Not if you use Yarn's zero-install or PnP or whatever they call it. It doesn't create node_modules and thus it's not very compatible, and that's the problem everyone is complaining about.
They each generate their own lockfiles that contain the dependency graph so they can’t be used together. They have different utilities in the CLI for example- NPM has npm audit, which yarn doesn’t. They’re mostly the same but you have to keep in mind they have different philosophies in how to manage the dependency graph.
TLDR: Choose one, stick with it, try not to have multiple node versions per machine/VM if you can help it, and update & test your packages in small frequent increments if you can. Otherwise it gets to be a nightmare real quick.
Yarn 1.x came out because NPM was really slow and buggy back in the day. Yarn was fast and buggy. Then Yarn 2 came out, was even faster and less buggy, but not backward compatible. I've never actually seen it used in the wild, even now (it's just yarn and NPM on all the projects I've worked on).
Bigger differences will come trying to upgrade multiple packages at once, especially across major versions (e.g. 2.x to 3.x). It's going to be hard no matter what, but `yarn upgrade-interactive` makes it a bit simpler, while npm has third party plugins that do similar things. There's also complexities involved if you need to switch the underlying `node` version across projects, since npm and yarn both need different node versions depending on their own version.
Their final outputs are similar (a node_modules folder where all your JS dependencies and sub-dependencies live), but their internal workings are different, and you shouldn't use both together because they will conflict with each other (sometimes).
Generally, switching back and forth isn't hard on smaller projects: just delete the lock files and delete the node_modules folder and reinstall everything from scratch.
But you really don't want to get into the habit of doing that. There's no real benefit (just choose one and stick with it; either is fine these days), and you may introduce hard-to-catch bugs related to one of your thousands of dependencies. Especially on bigger projects, erasing the lockfile means that it will try to use the designated SemVer in your package.json to get the desired version, but that may be different than the actual version that was being used, which is stored in the lockfile as a manual override. I'm not sure why these package managers had two sources of truth, but it's a nightmare.
0. JS world is full of people captivated by shiny things.
1. yarn was a shiny version of npm
2. They did a Python 3 stunt (well...much worse) with yarn 2 so nobody uses it and everyone stuck with 1.x
3. Bugs aren't fixed in 1.x
4. So back to npm, or the next shiny thing.
Edit: no you can't switch back and forth. The tools end up storing internal state in your project repo. I mean, yes you can change, but it'll mean some hassle and possibly re-writing build files.
> 0. JS world is full of people captivated by shiny things.
I mostly write C code these days, so I decided to checkout node to see what it was all about, and the shiny thing is spot on. A number of things that I looked at were described as "old" by people because they had been replaced by the new hotness a few months back.
Don't let that dissuade you too much. Yes, the community likes shiny, but you're not forced to upgrade if you don't like shiny. Just pin your versions and be happy.
And it was so much better that if they hadn’t pulled the python 3 but worse stunt I suspect a significant number of projects would have continued using yarn even after npm had caught up in terms of features and performance.
