There were times when we had only npm but it had so many issues with resolving dependencies and caching that another tool has born (yarn). Usually it was using local cache to resolve dependencies and it was crucial for example while running CI jobs which are almost always ran in same environment and high bandwidth is costly as you pay for data in cloud services. That means in old npm versions when you ran npm install and you had lets in depsFirst note:- Please understand that yarn was built on the top of npm packages and https://www.npmjs.com/ that means they are both using NPM registry for resolving packages. so if you run npm install [email protected]. or yarn add [email protected]. you will get very same resultIncremental install [email protected] [email protected] every new build both dependencies were again downloaded from internet. Yarn uses yarn.lock underneath and it is comparing your package.json file with yarn.lock and determines which packages needs to be fetched additionally to only incrementally install new dependenciesMultithreading yarn offers parallel installation of packages which are not dependent in threads. It can lower installation time to 1/10 of time from npm installVersion locking As said before yarn generates yarn.lock after each installation which persists ALL versions of installed packages (as you probably know package can has also dependencies and dependency can have also dependency) so it can build up infinite tree of dependencies which can lead to very bad conflicts. Let's imagine this scenarioapp- lodash^1- [email protected] - [email protected] [email protected] - [email protected] scenario when maintainer of another_module decides to bump lodash to breaking changes version 1.2.0 what can happen is that npm in old days could fetch 2 different instances of same library, and 2 different version which could lead to extremely weird behavior. Because as you don't have exact lock in your module (you accept any semver version ^1.x.x and ^2.x.x so that means both sub modules would satisfie your requirements but fetch different version. Yarn will lock your yarn.lock AT THE TIME OF AN ADDING new package to the project, that means when other developers on your project will checkout the project he will also have same yarn.lock and yarn will ultimately "mimic" the state of package how they were installed when you committed yarn.lock on other hands NPM just looks to the semver satisfaction and can fetch 2 different version for 2 developers (assuming that in time packages are upgrading)Final note:- There has been a lot of work from npm guys as they released npm@5 and I think all statements are now just reasons WHY yarn was created and which problems it was solving at the time, but I think at current date, it is no big difference between those 2 nowadays

Yarn has a few differences from npm. First of all, Yarn caches all installed packages. Yarn is installing the packages simultaneously, and that is why Yarn is faster than NPM. They both download packages from npm repository. Yarn generates yarn.lock to lock down the versions of package’s dependencies by default. On the contrary, npm for this purpose offers shrinkwrap CLI command.nstalling Yarn: sudo apt-get update && sudo apt-get install yarn Then we need to remove our node_modules folder and install all packages with Yarn: yarn install Yarn uses and stores all the packages that were installed in your local cache. When you are installing the package, Yarn is looking for the package in the local cache, and if the package is not found, then Yarn tries to download it from the Internet.

Yarn is an abstraction layer over npm developed by Facebook to address some of the issues with npm itself, namely speed and lack of reproducible/deterministic results.In yarn speed is improved by using parallel installations, offline caching and request queuing. Determinism is achieved by usages of the lock file which saves version of dependencies and their dependencies.Except those biggest differences yarn has a different CLI commands and has a more pleasant (less verbose) terminal output