NPM and yarn

When I started work on Monday, my colleague JJ familiarized me with the new project based on React. In the past, my steps have been:

git clone xxx
npm install
npm run dev
Copy the code

At this time, JJ gave me the following paragraph

git clone xxx
yarn
yarn start
Copy the code

“Why, what the hell is Yarn? Is NPM a more advanced alternative? Why replace NPM? Is there anything good about it?” A series of internal problems bubbled up. I silently asked JJ, “Is YARN the same thing as NPM?” “” HMM. JJ was busy typing at the keyboard, and it was clear that the question was no longer worth asking. I also silently wrote down a series of questions in my mind.

What is Yarn?

“Yarn is a new JS package management tool from Facebook, Google, Exponent and Tilde. As the official documentation states, Yarn has emerged to address some of the shortcomings of NPM.” This sentence reminds me of the pit when using NPM:

NPM install is extremely slow. In particular, new projects take a long time to pull down, delete node_modules, and install again. The same project cannot be installed consistently. Because of the version numbers in the package.json file, the following three version numbers represent different meanings at installation time.

“5.0.3.”

“~ 5.0.3”,

“^ 5.0.3.” “

5.0.3 indicates the specified 5.0.3 version, ~ 5.0.3 indicates the latest 5.0.x version, and ^5.0.3 indicates the latest 5.x. X version. This is troublesome, there will often be the same project, some colleagues are OK, some colleagues will be because of the installed version is not consistent with the bug.

At installation time, packages are downloaded and installed at the same time, and at some point halfway through, a package throws an error, but NPM continues downloading and installing packages. Because NPM prints all the logs to the terminal, the error information about the error package gets lost in a bunch of warnings that NPM prints, and you never even notice that the error actually happened. With these pits, I began to understand the advantages of Yarn and the problems it solves.

The advantages of Yarn?

Speed is fast

The fast speed mainly comes from the following two aspects:

Parallel installation:

Both NPM and Yarn perform a series of tasks during package installation. NPM executes each package in a queue, meaning it must wait until the installation of the current package is complete before further installations can proceed. Yarn synchronizes all tasks to improve performance.

Offline mode:

If a software package has been installed before, it is retrieved from the cache during the re-installation using Yarn instead of being downloaded from the network like NPM.

Unified Installation version

To prevent pulling to different versions, Yarn has a lock file that records the version number of the module that is exactly installed. Each time a module is added, Yarn creates (or updates) the yarn.lock file. This ensures that the same module version is used each time the same project dependency is pulled. NPM also has a way to use the same version of Packages everywhere, but requires developers to run the NPM shrinkwrap command. This command will generate a lock file, which will be read when NPM install is executed, just like Yarn reads the yarn.lock file. The difference between NPM and Yarn is that Yarn generates locking files by default, whereas NPM generates npm-shrinkwrap. Json files for shrinkwrap are generated by NPM. Packages version information is logged and updated.

Cleaner output

The output of NPM is verbose.

When NPM install is executed, all installed dependencies are continuously printed from the command line.

Yarn, by contrast, is much cleaner: by default, it combines emoji to print the necessary information visually and directly, and also provides commands for developers to query additional installation information.

Multi-registration source processing:

All dependencies, no matter how many times they are referenced indirectly by different libraries, are installed from only one registered source, either NPM or Bower, to prevent confusion and inconsistency.

Better semantics: Yarn has changed the names of some NPM commands, such as YARN add/remove, to feel cleaner than NPM’s original install/uninstall.

Contrast the Yarn and NPM commands

npm	yarn

npm install	yarn

npm install react --save	yarn add react

npm uninstall react --save	yarn remove react

npm install react --save-dev	yarn add react --dev

npm update --save	yarn upgrade
Copy the code

The future of NPM: NPM 5.0

With yarn pressure, NPM has made some similar improvements.

Package-lock. json similar to yarn.lock is added by default.

Git dependencies support optimization

This feature is useful when you need to install a large number of internal projects (such as Intranet development without a home-built source), or when you need to use some unreleased version of a dependency. Prior to this, you may need to specify commit_id to control the version.

File dependency optimization

In previous versions, if you installed the local directory as a dependency, you copied the file directory as a copy to node_modules. In NPM5, this will be done by creating Symlinks instead (except using a local tarball package) rather than copying files. This will speed up installation. Currently, YARN does not support yarn.

conclusion

Prior to NPM5.0, the advantages of YARN were particularly obvious. But after NPM, we can see from the above series of comparisons that NPM5 has really improved in speed and usage, and is worth trying, though not yet better than YARN.

To conclude, my personal advice is that if you are already using YARN on your personal project and have no further problems, you can continue to use yarn for the time being. But if you have NPM-compliant scenarios, or are on a team that uses NPM, CNPM, TNPM, or a project that has not yet made the cut to YARN, now is the time to try NPM5.

This article from Jane books Simbawu authors www.jianshu.com/p/254794d5e…

I made some formats, and I hope you’re comfortable with them