How does NPM manage versions of dependent packages

How does NPM manage versions of dependent packages

I ran into a dependency package versioning problem while writing the project, so I documented it here.

Use the precision attribute of the element-UI InputNumber component for local development, which is fine for local development, and then test it and find that the precision attribute does not work. There are several possibilities for this problem:

1. The code for the test environment is not updated.
2. The test environment’s InputNumber component does not have this precision attribute;

Then look at the code for the test environment and see that it is the same as the native code. This may be a precision problem. The InputNumber component’s Precision attribute was added in version 2.4.0. The InputNumber component’s precision attribute was added in version 2.4.0. So the test environment InputNumber component does not have this precision property and therefore does not work. The reason why I’m good locally is because I re-installed the dependencies at some point, so my native version of Element-UI is 2.4.*.

After this problem occurs, in order to avoid this problem again, how to implement the locking dependency package version number.

Here’s how NPM manages the version of project dependencies:

1. This section describes semantic version numbers
2. Avoid the optimal version number to resolve version inconsistency
3. usenpm shrinkwrapResolve version inconsistency issues
4. Local installation is better than global installation

Semantic version number

NPM defaults all Node packages to semantic version numbers. This is a set of rules that guide developers on how to increase version numbers, requiring:

1. Each version number is in the shape of 1.2.3 and consists of three parts, namely, “major version number”, “minor version number”, and “Revision Number”.
2. Raise the major version number when the new version is incompatible with code based on the previous version;
3. If the new version has added functions and features but is still compatible with the code of the previous version, the version number of the later version will be increased.
4. When the new version only fixes bugs or enhances efficiency, but is still compatible with the code of the previous version, the revision number will be increased;

By default, NPM install –save downloads the latest version and registers an optimal version number in the package.json file. When we look at package.json files, we might see these two cases ^2.4.0 and ~2.4.1, where the optimal version number is preceded by an extra “mark”, ^ meaning that the downloaded package may be a higher minor or revision number, and ~ meaning that a higher revision number is possible.

If you want to ensure that the dependencies downloaded by users and other developers are compatible with our code, there are two ways to lock your project’s dependency version numbers.

Avoid the optimal version number

The easiest and quickest way is not to use the optimal promulgation number. For version numbers recorded in package.json, simply remove the tags ^ and ~. This method is simple, but has one drawback: it cannot lock the version numbers of secondary dependencies. For example, if your project relies on a particular version of element-UI, you can untag the optimal version in package.json as described above. This version of element-UI has its own package.json, where the dependencies recorded are likely to use the optimal version number. So this is a little bit more complicated.

Run the NPM shrinkwrap command

The key issue now is how to lock the version number of the dependency. NPM has a directive to solve this problem: NPM Shrinkwrap.

When you get to a point in your development project and everything runs smoothly, all the dependencies are currently compatible with your code. At this point, you can run the above command in your project folder. It generates an NPM-shrinkwrap. Json file that records the current version information of all dependencies (and lower-level dependencies). So when someone else runs NPM install in the future, NPM will first find the npm-shrinkwrap. Json file and install each dependency package exactly according to the information. NPM will only use package.json if the file does not exist.

Local installation is better than global installation

NPM installs dependencies in two modes: local and global. Local installation means that dependency packages are downloaded into the node_modules file of the current project, while global installation installs them into the system-level directory.