I want the Yarn guys to make NPM better, so I don't have to learn two different tools. That's all I care about, so I can get on with my goddam app.

Speed: yarn is still faster
Workspaces: monorepos are taking over!
Lockfile: npm lockfile is still unreliable
Cache: yarn cache is way easier to handle (for example to use in docker builds)

And more and more... basically npm is for starting out, but once you start working on serious projects npm is still far behind yarn

Let's see...

- npm still doesn't have a cache
- npm still has unnecessarily verbose output
- npm install updating the lock file - what's the point of having a lock
file, if it's not used to lock down the versions unless you
specifically tell npm to upgrade? I've never seen a yarn.lock file
change unless I changed dependencies.
- "npm link" is inferior to yarn's link. It should simply create a symbolic link that just works. That's it.
- (a minor thing) npm help is useless. Just try running "npm help config", like npm suggests itself and let me know what you learned from it... (I'm on v6.4.1)

If anything, I'm wondering why in 2018, people are still using npm.

Hi, npm install is maybe the wrong cli if you don't want to update packages... npm ci will be your friend!
Maybe my article can help you understand better, otherwise I suggest to read the documentation of npm. Cheers

`pnpm link` is the best. And `yarn` workspaces are vastly inferior to `pnpm`'s.

pnpm does seem like the best out of the 3 at least conceptually.

I've only briefly tried it (it had issues that have since been resolved) but the thing is - I don't want to keep the command sets and intricacies of 3 different tools in mind. If either now or yarn dies, I'd probably start using pnpm.

All `pnpm` commands (besides `recursive` modifier, which is about monorepos and just runs the same command in all projects) are the same as `npm`'s. All commands it does nothing special for are essentially passed through.
Even `link` has the same syntax as `npm`'s. It just works better.

I do know the yarn alternatives well, and I think yarn is more ergonomic in some things, but if one knows npm one can use pnpm instantly.

Only found & started using yarn because `npm install` (even today w/latest npm 6.4.1) randomly deletes modules installed from github and dicks up the entire project. Deleting & re-adding node modules doesn't fix it. They "fixed" this like 2yrs ago, then locked/archived the gh repo & made it harder to submit issues. Yarn installed all the dependencies w/o issue and didn't randomly/inexplicably delete things for no reason, which is sort of the critical minimal desired functionality you need in a pkg mgr.

True. GitHub-based repos are PITA in NPM.

Because npm still fucks things up in his lock file. Not with packages which are in there repository, but with git versions. When you don't want to define the git version hash in the package.json, but trust that npm will take the one use by the lock file, you are fucked. Because npm will you the current master by a install.

for ci builds use 'npm ci' instead of 'npm install' and you can skip the lockfile step and that will be much faster. You should be specifying your versions if you want them to remain static.

> You should be specifying your versions if you want them to remain static.
Isn't this the whole point of a lock file? To lock versions so that they are consistent between environments.

yes this is the point of lockfile in theory. but it still does not work because there is plenty of usecases where using yarn command will regenerate lockfile. there is no reliability in semver - it is just a children story

Lol what? 1) `ci build` does not skip `package-lock` (it would make no sense if you know what `ci` is doing). 2) you should not try to pin your versions in `package.json`, it's worthless as those "pins" don't affect the deps of deps (that's why `package-lock` is invented).

"2) you should not try to pin your versions in `package.json`"

LOL WHAT?
you SHOULD pin your version.

you tell what version you need, your deps deps too and then lock tells you "here's the version I found to satisfy everyone". If none, it fails (expected).

If you don't pin the version (it can be subtle with ~>), you might jump from a major release to another automatically and end up with dramatic bugs

"you might jump from a major release to another "

What? Neither npm nor yarn has this behavior. "^1.0.0" will NEVER resolve to anything else than "1.x.x", nor "~1.0.0" to anything but "1.0.x".

The only way you could possibly get an "unexpected" major version bump is if you specify an asinine, open-ended version range. This is not default behavior in either package manager and is purely the work of people.

Neither npm nor yarn has this behavior. "^1.0.0" will NEVER resolve to anything else than "1.x.x", nor "~1.0.0" to anything but "1.0.x".

Read my comment again

package.json has no notion of "deps of deps". package-lock.json has. You're completely confused so pls. stop writing me and go learn stuff instead.

For a long time I felt like the last hold out for a move from npm to yarn!

However I've recently made the switch, mainly to make use of yarn-workspaces, and it's really nice. NPM learn a lot of what yarn provides and it's very encouraging to see them taking new features on board. (npm@7 has workspace support penciled in).

I use yarn to manage my workspaces and lerna to publish.

I think the most important message is to continue to evaluate your tools, whether they are build tools, development tools, languages, hosting. Doesn't matter, just keep adapting and improving!

I suggest you to use https://bitsrc.io/ instead of lerna.

yarn workspaces do have the advantage of deduplicating common modules used across a monorepo (something that Lerna doesn't do), saving significant disk space. Npm doesn't have that feature, but pnpm does, and it does it better than yarn workspaces.

I believe the term is hoisting. And Lerna definitely does that right now. https://github.com/lerna/le...

I've been in the deep abyss that is the npm source code. Run-time generated lambda functions everywhere which makes it a total pain to debug. I believe this is the main reason Facebook decided to build yarn to begin with rather than trying to fix npm.

Not for me (at least on Windows)...

Your test with 3 packages: next, react, react-dom took:
npm: 17.44 / 14.20
yarn: 14.25 / 7.47

Then I did swap the order and the results are:
yarn: 13.50 / 6.99
npm: 22.35 / 13.94

Info:
node 10.13.0
npm 6.4.1
yarn 1.10.1

yeah i have been bouncing around from npm to yarn between projects with similar dependecies. Yarn still seems faster, im on mac. It did get built more recently.

Yarn has had serious paralellism issues a couple of years back - and I imagine it is still the case. Try `yarn installing` into a couple of nodejs projects run in docker (all images pointing to a single yarn cache directory, mounted from docker host, and all starting up in parallel): you'll end up with corrupt package.json and yarn-lock files - some will have just half the data written out, some will have multiple json root docs in them.... yarn is a mess.

Just wanted to point out that currently there is a well maintained Yarn Version Manager similar to nvm called yvm: https://github.com/tophat/yvm
Maybe, it's worth updating this article since it's a top result on Google for "npm vs yarn".

Just wanted to point out that you are employed by Top Hat, the creators of yvm: https://github.com/orgs/top...

Can you please also post links to articles that describe the yarn version inconsistencies regarding lock files?
I tried for almost half an hour to find out more about this (have never run into issues with it myself) but aside from this article, I find no mention of it.

npm is just as fast as Yarn.

Not really.

I'm not switching just because.

I switched from npm to yarn because I had a problem to solve.
I'll switch from yarn when I'll have a problem to solve.

You make it seem like it's just fads.

I couldn't agree more! Yarn is one of those tools that burst onto the scene and seemed to gain widespread love for no apparent reason. Even at the start it gave only marginal benefits that in my estimation didn't help *most* people, and those benefits over NPM quickly diminished to near zero with NPM5. I'm usually skeptical of new trends but I always try before I judge, so when Yarn came out and my team was fawning over it, I agreed to give it a try and converted our large project and small team to use Yarn instead of NPM. This didn't turn out so simple, it required getting everybody to use a new tool, updating support code like build automation and internal tools, update documentation, etc. It was a fair amount of work, introduced confusion and friction with new developers, and guess what? It was a big waste of time. The "deterministic" builds turned out to be not quite as deterministic as promised, and we were already using npm-shrinkwrap (the older equivalent to package-lock that predated yarn). The speed upgrade was noticeable and nice but was realistically saving us a minuscule amount of time (re-installing is not a frequent task), and a few months later NPM 5 came out with all the same stuff. I finally ditched yarn and converted back to NPM for the same reasons you listed here. There's lots of 3rd party package managers for Node, why is Yarn so special? I snicker every time I see a readme say "npm install foo or yarn add foo"...

Reading some of the more extreme ‘wait, what’ claims in comments here, I keep feeling tempted to engage and then think better of it. I’m glad someone has already articulated this stuff — what you described matches my experiences closely.

One of the examples in which npm still causes bugs that arent fixed yet, and yarn "just works": https://github.com/webpack/... ;/

I'm curious about how you get the `npm run` autocompletion in your terminal. Is that a zsh plugin or something else?

https://docs.npmjs.com/cli/...

It's built into Fish shell by default.

I don't want to sound super pedantic, but is there any reason why you're using brew to install yarn, rather than just running `npm install -g yarn`? I've found this to be sufficient for my yarn needs, even when developing using React on Rails.

Hey Eric, you don't sound pedantic to me! I used brew because it's what Yarn recommends on their install page: https://yarnpkg.com/en/docs...

run `echo $PATH` - also run `yarn global dir` and `yarn global bin` do those paths take precedence over the `node_modules/.bin` dir when running `which npm`?

Does `yarn global bin` show up in your $PATH at all?

If you randomly add `RUN npm i -g yarn` and then `RUN yarn global add blah` to a Dockerfile, without installing yarn correctly, you'll start to see why... tl;dr (one reason i've noticed in practice at least)

yarn is still better than npm (in 2019). Yarn workspaces work _with_ lerna, it's not either/or, and using them together has advantages over using lerna + npm. Especially, you should be using yarn if you are using lerna. In my opinion, of course

Lerna doesn't have sufficient documentation

I recently switched to pnpm. It's great. Saves a ton of space and often even faster than yarn, because it doesn't create dozens of copies of the same things--it downloads one copy per version of each package that is needed, and then creates links as appropriate. It now seems nuts to do it any other way.

https://pnpm.js.org

this article convinced me to switch back.
so i did, and this is the first thing that happend:
https://uploads.disquscdn.c...
never switching away from yarn again
i can't delete these by the way, which makes it even more fun

yarn is still faster for me, like twice as fast.

I tried switching back to npm, but yarn is still dramatically faster. I've read posts that claim to have done rigorous tests and that the difference is small... But that's not my experience at all.

To those who say less typing is an advantage though, have you guys never heard of aliases? Pretty much everything I do with yarn or npm, I do with 2~3 letters.

Are you talking about bash aliases?

I work on piles of different projects with different structures and commands, so setting up global aliases for commands in specific projects isn't great.

Well, I wouldn't make a global alias for commands in specific projects... But you could create an alias for 'npm run', say nr, which is shorter even than yarn, and then type nr <scriptname>. You could even make it one letter, if you wanted.

I love the way this article touches all the pain points!

Glad you enjoyed, thanks for the comment :)