** npm version number form XYZ**
where X, Y and Z are non-negative integers, and it is forbidden (MUST NOT) to add zero before the
number. Version format: major version number. minor version number. revision number, version number increment rule as follows:
X. Major version number: When you make incompatible API modifications,
Y. Minor version number: When you make downward compatibility functional additions,
Z. Revision number: When you make downward compatibility problem corrections .
Explanation of the symbols before the version number
1. There is no symbol.
1.0.0
is a 100% match. The current library/project must use the current version number. If a different version of the same library is used with other dependencies, one will be created under the library folder The node_modules folder stores the version files it needs to depend on.
2.> (greater than)
must be greater than a certain version.
For example, >1.0.0, versions 1.0.1, 1.1.1 and 2.0.0 can be used.
3. >= (greater
than or equal to) must be greater than or equal to a certain version number.
For example, >=1.0.0, versions 1.0.0, 1.1.1, and 2.0.0 can be used.
4. <(less than)
must be less than a certain version.
For example, <2.0.0, versions 1.0.1, 1.1.1, and 1.1.9 can be used.
5. <= (less
than or equal to) must be less than or equal to a certain version.
For example, <=2.0.0, versions 1.0.1, 1.1.1, and 2.0.0 can be used.
6. ~
Do not change the major version number and minor version number, the revision number can be changed at will.
For example, ~2.0.0, you can use the 2.0.0, 2.0.2, 2.0.9 version.
7. ^
Do not change the major version number (the major version number is not 0), this version number and revision number can be changed at will.
For example, ^2.0.0, you can use the versions 2.0.1, 2.2.2, and 2.9.9.
8.
The position of x and the following position can be arbitrary (not on the main version number).
For example, 1.x can use versions 1.0.1, 1.1.1, and 1.9.1.
For example, 2.1.x can use 2.1.1 and 2.1.9 versions
9. *
* means that any version has no restrictions on the version, generally not used
"base": "*"
10
.--indicates the version between the two version numbers
"base": "1.0.1-1.5.9"
For example, 1.0.1-1.5.9 can use any version between 1.0.1 and 1.5.9
11.||(or)
|| can be used to set multiple version number restriction rules,
such as >= 3.0.0 || <= 1.0.0 You can use the version number greater than or equal to 3.0.0 or use the version number less than or equal to 1.0. 0
Points to note
When installing dependencies for the first time, npm will generate a package-lock.json file, and yarn will generate a yarn.lock file to fix the dependencies at the current point in time, even if node_modules is deleted.
If the project/library changes the dependent version, it is best to delete yarn.lock and node_modules and reinstall. If not, the dependency relationship will be disordered, and unnecessary files will be generated in the original dependency.
For example, both the project and one of lib1 depend on different versions of a package
lib1: depends on'base':'^1.1.0'
project depends on'base ':'1.2.0'
The first installation will place the base library (1.2.0) version in the node_modules root directory.
Adjust the dependency
lib1: depends on the'base':'^1.1.0'
project depends on the'base ':'1.7.0'
If you do not delete yarn.lock and node_modules and install again, there will be a separate [email protected] version in the lib1 folder at this time.
Because the base version that lib1 relies on is 1.2.0 when it is first installed, after yarn_lock locks the version, npm will always think that lib1 is dependent on base: 1.2.0,
even the latest base1.7.0 also conforms to lib1's'base' :'^1.1.0', lib1 will also look for a matching dependency package [email protected] according to the directory.
So not deleting yarn_lock and node_modules may cause confusion in dependencies