preface

The reason for writing this article is that I suddenly noticed the version number in package.json two days ago, I seem to have not noticed it. Then I thought about it and realized that I didn’t really know about it. Every time I opened a project, NPM install just clicked the startup command. I thought about it a little bit and decided it wasn’t a good idea if someone came to you one day and asked you what “XX” meant and you couldn’t tell me how embarrassing it would be, so I got this article.

The body of the

1. npm

Before introducing package.json, we need to introduce NPM. NPM is a public registry that contains many Javascript packages that open source developers can contribute to or download for their own projects.

A description of package and Modules can be found in the official documentation.

About packages and modules

2. package.json

Package. json is used to manage packages. To publish a package to NPM, you must include a package.json file.

The package.json file does the following:

  • List the packages your project depends on;
  • Identify the versions of packages you can use in your project;
  • Make your packages secondary development and easier to share with other developers;

Create package. Json

You can create the default package.json file either from the command line or directly.

Command line: Go to the project directory -> NPM init and create via command line interaction.

Customize the command line interaction to create package.json: see init-package-json

Create a default file: You can directly generate a default package.json file using information extracted from the current directory. Enter the project directory – > NPM init – yes | NPM init – y

We can also configure the configuration item of the initialization command to set the default value:

> npm set init.author.email "[email protected]"
> npm set init.author.name "example_user"
> npm set init.license "MIT"
Copy the code

3. The configuration items

name

Configuring the name and Version fields is mandatory and important if you are publishing your package; If publication is not required, name and Version are optional.

There are some restrictions on the name and Version fields:

  • The name contains a maximum of 214 characters. If it is a scoped package, it also contains its scope.
  • The name of the scoped package can be.or_At the beginning. Non-scoped packages are not allowed.
  • The name of the new package cannot contain uppercase letters.
  • The name will eventually become part of the URL/ command line parameter/filename, so the name cannot contain non-URL-safe characters.

version

Version is as important as name for the package to be published. Version must be resolvable by Node-semver.

description

Description helps people find your package using NPM Search.

keywords

Keywords are an array of strings. As well as description, it helps people find your package using NPM Search.

homepage

A URL that links to the project home page.

"homepage": "https://github.com/owner/project#readme"
Copy the code

bugs

Link to the URL of the project issue or the email address of the issue.

{
  "url" : "https://github.com/owner/project/issues"."email" : "[email protected]"
}
Copy the code

Both values are optional, so if you only want to use a URL, specify bugs as a URL string instead of an object.

license

Packages should specify a license so that other users know how your package can be used and what restrictions it has.

{
  "license" : "BSD-3-Clause"
}
Copy the code

In some older packages licenses were declared using an object or object array, which is no longer recommended.

author, contributors

Authors and contributors. It can be described by an object containing a name field, with optional URL and email.

{
  "name" : "Barney Rubble"."email" : "[email protected]"."url" : "http://barnyrubble.tumblr.com/"
}
Copy the code

Or you can abbreviate it to a string that NPM will parse automatically:

{
  "author": "Barney Rubble <[email protected]> (http://barnyrubble.tumblr.com/)"
}
Copy the code

main

The main field specifies the entry to the project.

browser

If your module is to be used on the client, specify the browser field instead of the main field.

bin

The bin field contains a set of command to local file name mappings. When installing a package, NPM creates a symbolic link to prefix/bin for a global installation, and to./node_modules/.bin/ for a local installation.

{
  "bin": {
    "myapp": "./cli.js"}}Copy the code

When we install myApp, it creates a symbolic link from cli.js to /usr/local/bin/myapp.

If you have only one executable command in your package and the command name is the same as the registration, you can declare it as a string:

{
  "name": "my-program"."version": "1.2.5"."bin": "./path/to/program"
}
Copy the code

repository

Specifies the location of the code repository.

scripts

The scripts property is a dictionary containing script commands that are run at different times in the package life cycle. Keys are life cycle events and values are commands to run at that point. See the Scripts.

dependencies

Dependencies is an object that contains mappings from package names to version ranges. A version range is a description string separated by one or more Spaces. Dependencies can also be identified with a tarball or git URL.

Note: Do not include tests, compilations, or other tools used during development in Dependencies.

For details about version ranges, see node-semver: README Versions.

Related reading: Semantic version numbers

Here are some common version ranges:

The operator meaning instructions
< Less than <1.2.7 will match version 1.2.6, 1.0.1, 0.0.2, but not version 1.2.7, 2.0.0, etc
< = Less than or equal to <=1.2.7 will match versions 1.2.7, 1.2.6, but will not match versions 1.2.8, 2.0.0, etc
> Is greater than >1.2.7 will match versions 1.2.8, 2.0.0, but not versions 1.2.7, 1.0.0, etc
> = Greater than or equal to >=1.2.7 will match versions 1.2.7, 2.0.0, but not versions 1.2.6, 1.0.0, etc
~ Match minor Version ~1.2.3: = >=1.2.3 <1.(2+1).0: = >=1.2.3 <1.3.0-0

~1.2: = >=1.2.0 <1.(2+1) 0: = >=1.2.0 <1.3.0-0

~1: = >=1.0.0 <(1+1).0.0: = >=1.0.0 <2.0.0-0
^ Match Compatible version ^2.3.1: Compatible with version 2.3.1 i.e. >=2.3.1 < 3.0.0 without changing the major version number

devDependencies

And testing, compiling, or other related tools used during development should be placed in devDependencies.

peerDependencies

In some development scenarios, your package needs dependencies that you don’t need to install because the host of the package installs them. Use peerDependencies to declare dependencies and versions. NPM alerts you to resolve these dependencies.

engines

You can use Engines to specify the version of Node that your package will run, or which version of NPM will run your program correctly:

{
  "engines": {
    "node": "> = 0.10.3 < 15"."npm": "~ 1.0.20"}}Copy the code

os

Can be used to specify the operating system on which your program is running:

{
  "os": [
    "darwin"."linux"]}Copy the code

Non-operators can also be used to disable running on an operating system:

{
  "os": [
    ! "" win32"]}Copy the code

cpu

Can be used to specify the CPU on which your application will run:

{
  "cpu": [
    "x64"."ia32"]}Copy the code

You can also use non-operators to disable running on a CPU, ditto.

private

If private: true is set, NPM will not publish your package. This is a way to prevent accidental publication of private libraries. If you want to ensure that a given package is only published to a specific library, you can override the configuration parameters when publishing using publishConfig.

publishConfig

This is a set of configuration values used for publishing. For details, see Config.

conclusion

Encounter do not understand or to read more summary, official documents is a good thing do not read because all in English ah

A link to the

  1. package.json
  2. About packages and modules
  3. init-package-json
  4. Scripts.
  5. Node – semver: the README
  6. Semantic version number
  7. The config.