NPM is the node. js standard software package manager. This article discusses the NPM mechanism and compares the differences between NPM, CNPM and YARN.

How do I install a single NPM package

The difference between Dependencies and devDependencies is not obvious in common front-end projects.

In a common front-end project, such as the VUE framework, the main purpose of both is to clarify which dependency packages are actually used in the project code.

You need to install both to run (because devDependencies usually include runtime environment dependencies).

In a pure Node project, this is different. Here is a look at the dependency configuration of a Node project.

NODE_ENV=production NPM I With devDependencies installed, the editor’s ESLint detection plug-in works, or you can use JEST for unit testing.

This is a true separation of the development environment from the production environment.

NPM install installs the Dependencies field and all modules in the devDependencies field by default.

When NODE_ENV=production NPM I, only the Dependencies module in the dependencies package is installed.

When you develop some third packages, you need to keep this in mind and place all the packages that your project depends on in Dependencies.

Also, don’t throw in a bunch of cluttered bags, which will make your bag too big.

How do I use or execute the NPM installed packages

Eslint, for example, generates a global command when executed globally.

However, there are some command packages that I only want to install and use in a particular project.

Add NPX, such as NPX eslint. NPX will first look for packages already installed in the project and then for packages that are globally installed. If none is found, NPX will install the package first and then execute the command.

Package. The json and package – lock. Json

Versioning system with package.json

NPM follows semantic versioning standards.

  1. What are semantic versioning standards?

To put it simply:

1.5.4 is the version number, where

  • 1 is the major version number, which represents incompatible API changes
  • 5 is the second release number, which represents a backward compatible functional addition
  • 4 is the revision number, which represents a backward compatible problem fix

Case 1:

If the main.any method was provided in 1.0.0 and removed in the new release, then you should release 2.0.0.

If a package often releases large versions that are incompatible with the previous version, the library should be reconsidered or it will soon get cold.

Case 2:

If the main method provided in 1.0.0 has the same effect as main.any in the new version, then you should release version 1.1.0, and main is one of the new methods.

Case 3:

If the main.any method was provided in 1.0.0, and some scenarios of the method were bug fixed in the new version, and the unit tests covered all scenarios, then you should release 1.0.1 to fix the problem.

If you are not sure if fixing the bug will cause some scenarios to behave differently, then you should release 1.1.0. Users who do not experience the bug in the original scenario and only update the revision number can avoid the problem.

  1. inpackage.json, how to configure the third-party package version?

Semver specification:

  • If ~ 0.13.0 is written, only patch version is updated: 0.13.1 is ok, but 0.14.0 is not.
  • If you write ^0.13.0, update patch and minor versions: 0.13.1, 0.14.0, and so on.
  • If 0.13.0 is written, the exact version is always used.
  • There are more rules, such as:>,> =,||“, but it should not be used very often, so I won’t expand the introduction.

In the case of vue scaffolding, the generated project dependencies look like this:

As you can see, the scaffold-related libraries all use a patch-only mode; The rest of the packages have opted for newer version numbers to introduce new features or optimizations that are retro-compatible.

Therefore, with package.json alone, the original project and the newly initialized project (with a high probability) are actually different.

Even if a patch release or sub-release should not introduce significant changes, it may still introduce defects (you can’t be sure exactly what every update to a third-party package you use does).

Locked version with package-lock.json

After npm@5, package-lock.json mechanism is introduced.

Package-lock. json solidifies the version of each package currently installed, and NPM uses these exact versions when running NPM Install.

In vue, for example, it is version ^2.6.11 in package.json, whereas in the actual installation, version 2.6.14 is installed and version 2.6.14 is locked in the package-lock.json file.

After the package-lock.json version is locked, leaving this file in your Git repository ensures that the dependencies of the original project and the newly initialized project installation are consistent.

If you want to update the version locked in package-lock, you can use the NPM update command (which does not update the main version) to update dependencies and update the version locked in package-lock to the latest version (still locked) under semver standards.

Why is the package-lock.json file so much bigger than the package.json package?

Because package-lock.json not only locks the dependencies in the project, but also locks the dependencies in the nesting way, the entire file can be very large.

Another problem is that NPM update updates all dependencies of dependent packages. For a project that has been running steadily for a long time, it is risky to upgrade a specific package (NPM I xx@version).

Package-lock. json (package-lock.json) : package-lock.json (package-lock.json) : package-lock.json (package-lock.json) : package-lock.json (package-lock.json) : package-lock.json (package-lock.json) : Package-lock. json (package-lock.json) : Package-lock. json (package-lock.json)

To find out how many versions of your package are outdated, type NPM outdated:

Latest is the Latest major version of the package, and Wanted is the Latest minor version of the package under the current major version.

Want to know the actual installed package version

  1. Stupid solution: Gonode_modulesLooking for inside.
  2. Be smart: Gopackage-lock.jsonLook inside, because it has locked the actual installed version.
  3. withnpm list --depth=0Look at the dependency package versions for the entire project.
  4. npm view [package_name] version

In practice, commands 3 and 4 are easy to forget if you don’t use them often. I used to use the first stupid method, and I will use the second method, which is obviously much more convenient.

Yarn and NPM

  1. Rely on the version

In the early days of Yarn, yarn.lock was used to lock the version, which was much better than package.json, but later NPM also introduced package-lock.json, so there is not much difference in this point.

  1. Install the speed

Yarn feels much faster than NPM because YARN installs dependencies in parallel, whereas NPM is serial.

In the cache mechanism, the current difference is not very big, will read the local cache.

  1. Use what?

Currently, in 2021, YARN is still installed faster than NPM. There is no significant difference in other places, so you can almost ignore it and use either.

Installation depends on too fast is not necessarily good, sometimes, the installation speed is slower, but also can drink a cup of tea root cigarette, have a rest.

In terms of design, yarn input is a little more ergonomic than NPM.

But with the company’s network, a lot of people use CNPM.

CNPM and NPM

  1. CNPM is much faster than NPM

Because CNPM mirror warehouse in China (Taobao room), much faster than NPM of course. But now NPM has added a caching mechanism to keep up with the speed. (Except for node-sass)

NPM install is called internally, so… Or slow.

You can also set the mirror source of NPM to Taobao mirror, which will also be much faster.

npm config set registry http://registry.npm.taobao.org

  1. CNPM no package – lock. Json

Package-lock. json is not generated when CNPM is installed, and even if package-lock.json is present in the project, CNPM will just read package.json regardless.

This mechanism may result in the dependency libraries in your code needing to be locked in package.json, otherwise… One day, CNPM may screw you over.

This is probably the biggest downside of using CNPM.

  1. On the second point, the author’s response

To this point, the CNPM authors respond that they do not support it now and will not consider supporting it in the future.

The authors mention that if the version is locked, many hidden bugs may be difficult to fix and may fall victim to a bug.

As the dependent version may be inconsistent in multiple environments, the author’s answer is to adjust the whole operation and maintenance release system, for example, after verification by CNPM in multiple environments, it is released to production. (For the author’s scheme, I think it is not very reliable, mainly because the cost and benefit are not proportional, not every front-end has so much energy)

If there is a bug that is not fixed, roll back the version directly to reduce the impact of the bug. (…).

Many people disagree with the author’s argument that the locked version is much less risky.

There is also the danger that the package you are using may not follow the Semver specification, it may send a patch version with a major overhaul, or there may be no unit testing at all (especially if you are using some of the less popular packages).

Even the more famous bags, for example, the Christmas Egg incident:

In the ANTD package, a Christmas egg was included in versions 3.9.3, 3.10.0-3.10.9, and 3.11.0-3.11.5.

On Christmas Day, all the Button components were snowflake Ed.

If at that time, you locked the version, then you have a certain probability of avoiding the problem.

If you don’t have a locked version, there’s a good chance you’ll fall for it.

  1. Some dependencies don’t work

Some dependencies will not work when installed with CNPM, but will work when installed with NPM. This problem is probably related to the way CNPM packages use soft links.

CNPM and NPM are mixed, causing the package to hang. This can be identified as the problem of CNPM using soft links. So try not to mix them.

  1. conclusion

If you can use NPM, it is better to use NPM. It is also recommended to make NPM for the private image source inside the company. After all, CNPM still has some hidden dangers.

The PNPM and NPM

See a lot of people amway, characteristic is fast.

I feel that this fast fast in the peacetime development process is not an advantage, also not bad this time.

Consider installing dependencies in production containers.

conclusion

Now that NPM is working, it’s better to use NPM.

If you have problems with installation speed, you can set up a private NPM image source and store some of the installed packages on the image source.

One last thing

If you’ve already seen it, please give it a thumbs up

Your likes are the greatest encouragement to the author, and can also let more people see this article!

If you find this article helpful, please help to light up the star on Github.