Let's talk about how to use package.json for version management of dependent packages

This article talks about how to use package.json to perform version management on dependent packages in actual front-end projects. What impact will different rules have on dependency management?

npm version number definition

Version format: X.Y.Z[-string]
The meaning is:

• X: Major version number
• Y: Minor version number
• Z: Correction version number
• string: Prior version number or version compilation information

For example:

6.3.2-alpha means:

• Major version number 6 , there are 6 update iterations that are not backward compatible.

• minor version number 3, there are 3 small function iterations. 6.*.* Any dependency statement of 6.3.2 can install this new package.

• Correction version number 2, there are 2 bug modifications or other non-major functional modifications. 6.*.* Any dependency statement of 6.3.2 can install this new package.

• Advanced version numberalpha, indicating the processing trial stage.

Extended reading:Semantic Version 2.0.0

How to identify dependency versions in package.json

will be interpreted as follows:

"vue": "~2.5.22",
"vue-class-component": "^6.0.0",
"vue-router": "3.0.1",
"express": "latest",
"mongoose": "*",

• Symbol^: Lock the major version, update the minor version number, revised version number and precedence Version number

  For example"vue-class-component": "^6.0.0", when installing dependencies, you can install it in line with 6.*.* Any version, as long as the major version number is 6.

• Symbols~: Lock the major version number and minor version number, and update the revised version number and advanced version number

  For example "vue": "~2.5.22", when installing dependencies, you can install any version that conforms to 2.5.*.

• Empty symbol: Lock all version numbers

  For example"vue-router": "3.0. 1", only dependent packages with version 3.0.1 can be installed.

• Symbol*: Define a certain version number range

  For examplevue-router": "3.0 .*", you can install any version fixed by 3.0, such as 3.0.1, 3.0.2.

• latest: Install the latest stable version

• ## For example,

  "express": "latest", you can install 4.18.1 (the latest version of 2022.06.13).

• *: Install the latest released version, not necessarily the stable version

##For example
• "mongoose": "*"

  , you can install 6.0.0-rc2, 3.9.7, etc.

• Git URL

  : Use packages published on GitQuote format:

  ://[[:]@][:][:][/][# | #semver:]

  ##

  "test": "git+ssh://git@github.com:npm/cli.git#v1.0.27"

  Extended reading:
npm docs - dependencies

Don’t trust the version number of the npm package too much!

As the title says, this is a bloody lesson. Experience.

When the author uses

system.js

, the version limit used is:

system.js: "^6.3.2". When installing dependencies, the version > 6.3.2

was accidentally installed, causing an error in project operation.

The reason is the author of system.js

, The version number was not named according to the

semver specification, which resulted in the author's project introducing not backward compatible updates, which caused the project to run incorrectly.dependencies, devDependencies and peerDependencies

dependencies

The dependencies used in the production environment are uniformly installed under dependencies

.

For example:

"dependencies": {
	"chalk": "^2.4.2",
	"commander": "^3.0.0",
	"fs-extra": "^8.1.0",
	"inquirer": "^6.5.0",
	"mem-fs": "^1.1.3",
	"mem-fs-editor": "^6.0.0",
	"shelljs": "^0.8.3"
}

The above code is a fragment from

package.json

of the

cli toolkit made by the author. shelljs is used to operate files. If it is declared in
devDependencies, an error will be reported after the user installs the current tool package. Because the dependencies declared in the devDependencies field will not be installed when
npm install tool package . It must be declared in the dependencies field to be installed.

devDependencies

生产环境不需要使用的依赖，都需要安装在devDependencies下。
因为生产环境下，是不会安装devDependencies字段下的依赖的。

举个例子：

"devDependencies": {
	"@commitlint/cli": "^8.1.0",
	"@commitlint/config-conventional": "^8.1.0",
	"commitizen": "^4.0.3",
	"commitlint-config-cz": "^0.12.1",
	"cz-customizable": "^6.2.0",
	"standard-version": "^7.0.0"
}

上述代码，是笔者做的cli工具包的package.json中的片段。
commitizen是笔者用于规范Git提交规范的依赖包，只在开发环境中使用，所以在devDependencies中声明。

peerDependencies

当开发一些插件和工具包时，对使用方的运行环境的依赖包版本有要求，可以使用peerDependencies字段进行声明。

举个例子：

{
  "name": "tea-latte",
  "version": "1.3.5",
  "peerDependencies": {
    "tea": "2.x"
  }
}

当前工具tea-latte，依赖tea包。而且，要求tea包是主版本2。

当不满足要求时，控制台会进行报错处理。

注意
npm v7版本， peerDependencies会默认安装。
npm  v3 到 npm v6版本， peerDependencies不会自动安装。

更多node相关知识，请访问：nodejs 教程！

The above is the detailed content of Let's talk about how to use package.json for version management of dependent packages. For more information, please follow other related articles on the PHP Chinese website!