Publish packages to the npm registry (below)

To specify the packages that the project depends on, declare them in the dependencies and devDependencies fields in the package.json file. When running npm install, npm will download package.jsonthe dependencies and development dependencies listed in . These dependencies and development dependencies must meet Version requirements for each dependency. To see which package versions will be installed, use the semver calculator .

"dependencies": Packages that your application requires in production.
"devDependencies": Packages for local development and testing only.

1.1 Add dependencies to `package.json 文件`

You can add dependencies package.jsonto the file via the command line or by manually editing the file.package.json

1.2 From add dependencies to`package.json 文件`

To add dependencies and development dependencies to a file from the command line , they can be installed in the root of the package package.jsonusing the dependencies --save-prodflag (which is the default flag for npm install ) or the devDependencies flag.--save-dev

To add an entry to "dependencies"a file's package.jsonproperties, run the following command on the command line:

npm install <package-name> [--save-prod]

Or npm install <package-name>, for example:

npm install jiang-isarray

1.3 Manually edit the package.json file

To package.jsonadd dependencies to a file, add a property in your text editor called "dependencies", which references the name and semantic version of each dependency:

  "dependencies": {
    "jiang-isarray": "^1.0.0"
  }

To add devDependencies to package.jsonthe file, in a text editor, add "devDependencies"a property called , which references the name and semantic version of each devDependency:

  "devDependencies": {
    "nodemon": "^2.0.22"
  }

2. About Semantic Versioning

To keep the JavaScript ecosystem healthy, reliable, and secure, every time you make a major update to your own npm package, we recommend publishing a new version of the package with an updated version number in a package.json file that follows the semantic versioning specification. Following the Semantic Versioning specification helps other developers who depend on your code understand the extent of changes in a given version and adjust their own code if necessary.

Note: If you introduce changes that break package dependencies, it is recommended to upgrade the corresponding version of the current package.

2.1 Add semantic version to published packages

To help developers who depend on your code, we recommend starting with 1.0.0your package version and incrementing it as follows:

code status	stage	rule	sample version
Initial Release	New product	since 1.0.0	1.0.0
Backward compatible bug fixes	Patch released	add third digit	1.0.1
Backward Compatible New Features	minor version	Increment the middle digit and reset the last digit to zero	1.1.0
Changes that break backwards compatibility	major version	Increment the first digit and reset the middle and last digits to zero	2.0.0

2.2 Use semantic versioning to specify the types of updates a package can accept

You can specify in the package's package.jsonfile which types of updates a package can accept from dependencies.

For example, to specify an acceptable version range (up to 1.0.4), use the following syntax:

Patch release version: 1.0 or 1.0.x or ~1.0.4
Minor version: 1 or 1.x or ^1.0.4
Major version: * or x

Dependency example:

  "dependencies": {
    "cookie-parser": "~1.4.4",
    "debug": "~2.6.9",
    "express": "~4.16.1",
    "http-errors": "~1.6.3",
    "jade": "~1.11.0",
    "morgan": "~1.9.1"
  }

2.3 Version Range Syntax Example

2.3.1 Include everything that does not increment the first non-zero part of semver, using the character "^"

for example

^1.0.1
^1.1.1
^0.0.3

NOTE: Caret behaves differently than 0.x versions, it only matches patch versions.

2.3.2. Specify the range of stable versions

Use >, <, =, >= or <= for comparison, or - to specify an inclusive range

for example:

>2.1.1
<2.1.0
=2.1.1
>=2.1.1
<=2.1.1
1.0.0 - 2.0.0

Note: There must be spaces on both sides of the hyphen

2.3.3 Specify the pre-release version range

Use comparisons like >

for example

>1.0.0-alpha
>=1.0.0-alpha<2.0.0

2.3.4 Include everything greater than a specific version in the same minor scope

Using the tilde notation, ~

举例说明

~1.0.0

2.3.5 includes pre-release versions such as `alpha` and/or `beta`

Use pre-release tags

for example

1.0.0-rc.1

The pre-release version is specified as exact version
. To specify the range

2.3.6 Contains multiple sets of versions

Use || union

for example

~1.0.0 || >2.0.0

3. Add dist-tags to the package

Distribution tags (dist-tags) are human-readable tags that can be used to organize and label different versions of a package being released. dist-tags complement semantic versioning. In addition to being easier to read than semantic versioning, tags allow publishers to distribute their packages more efficiently.

Note: Since dist-tags share a namespace with semantic versioning, avoid dist-tags that conflict with existing version numbers. We recommend avoiding dist-tags that start with a number or the letter "v".

3.1 Publish packages with dist-tag

By default, run will tag your package npm publishwith dist-tag. latestTo use another dist-tag, use --tagthe flag when publishing.

1. On the command line, switch to the root directory of the package.

cd /path/to/package

2. Run the following command, <tag>replacing it with the flag you want to use:

npm publish --tag <tag>

3.2 Adding a dist-tag to a specific version of a package

1. Add a dist-tag to a specific version of a package

cd /path/to/package

2. Run the following command, <package_name>replace with the name of the package, <version>replace with the version number of the package, and <tag>replace with the distribution flag:

npm dist-tag add <package-name>@<version> [<tag>]

3.3 Examples

To add the "stable" flag to version 1.4.0 of the "example-package" package, you can run the following command:

npm dist-tag add [email protected] stable