(according to me)
Todo: Review these to make this more comprehensive
- https://yarnpkg.com/en/docs/migrating-from-npm#toc-cli-commands-comparison
- https://shift.infinite.red/npm-vs-yarn-cheat-sheet-8755b092e5cc
- https://github.com/pnpm/benchmarks-of-javascript-package-managers
There was a time when Yarn's benefits over npm where dramatic. It yielded consistent installs on any host with yarn.lock and it was significantly faster (see https://engineering.fb.com/web/yarn-a-new-package-manager-for-javascript/). However, npm these days is faster (last time I checked) and npm's package-lock.json fixes the consistency issue on npm now too.
First and foremost, you don't need to type run. Just type yearn <script name> and yarn runs the script.
Passing additional options ot the script is easier in yarn. For example if you have a script named docker-compose to use it in npm you have to type:
npm run docker-compose -- restart
On yarn you type:
yarn docker-compose restart
To add a package in npm you must add the --save or --save-dev or it will not be added to package.json. So you might think that npm install
Where as with yarn you type yarn add <packagename> it will always be added to package.json.
Unbelievable that npm didn't add this the next day after it appeared in yarn: npm/npm#18067
Yarn has native support for mono-repos with workspaces. NPM does not and relies on third party lerna package. Also asked and answerd on SO.
The biggest benefit to npm is that it is universally supported and yarn is not. For example see the GitHub Package Registry documentation and notice how they refer to npm but never yarn. In the vast majority of cases yarn will just work exactly the way that npm does, but not always. And when it doesn't you have a real head scratcher and you're constantly tempted to rever to npm to see if ruling out yarn will resolve the issue.