[TOC]
preface
One of the first things you learn about the front-end when you get started is the package.json file that accompanies all front-end development.
So the question is, have we really looked inside the document, looked beyond the surface, looked inside the document?
1. Field description
1.1 the name
Definition: Name is used only as the project name in a non-distributed (uploaded to the NPM library) project. In the case of a project distributed as a module, plug-in, or library, name is not only a project name but also defines the name of your installation on the package management site.
{
"name":"projectname"
}
Copy the code
**^(?) **^(?) :@[a-z0-9-*~][a-z0-9-*._~]*/)? [a – z0-9 – ~] [a – z0-9 – _ ~] $* * *, the rules of examination is to allow only a /, @, and are all lowercase.
Version 1.2
Definition: Version defines the version iteration schedule of the current project.
At present, many projects do not care much about the management of version number, but more about the product version number. Some projects use the method of product version number + Git hash code.
Generally, the version number is **[x,y,z]**. X,y, and Z are major, minor, and patch versions respectively. The version is usually a regular number, incremented by 1 each time it is updated.
Main version (X): your project big change, change the mother do not know, before using your project basic BOOM.
Version (Y): Tweaked a lot of things, added a lot of features, but used to be basically stable with your project.
Patch (Z): Fix your own patch and add some details that don’t affect your project at all.
For more information, see the semantic version number, which is the default recommended version number documentation.
1.3 scripts
Definition :scripts specifies the NPM command line abbreviation for running script commands, such as serve specifies the command to be executed when running NPM run serve.
The contents of scripts in our initialized project look like this:
{
"scripts": {"serve":"vue-cli-service serve"."test":"jest"}}Copy the code
Scripts can be configured to specify the commands to run after NPM. When we initialize projects like VUE, React, etc., the tools have already configured the commands for us and we just need to use them out of the box.
How do YOU run a command? After we install Node, node configures a global command for us, NPM.
npm run serve
Copy the code
Running this command is equivalent to running in the current directory:
vue-cli-service serve
Copy the code
You can think of scripts as command abbreviations.
1.4 dependencies
Definition: Specifies the module on which the project runs
Modules installed this way add module packages to Dependencies, and your project cannot run without this module.
npm install packageName --save
Copy the code
After installation, add the following to your package.json:
{
"devDependencies": {"packageName":"version"}}Copy the code
PackageName: indicates the name of the third-party package
Version: The version number of the installation. This version number supports ^,’~’,’laster’. For example ^1.0.0 says you can install versions after 1.0.0. Sometimes the version number is locked to 1.0.0 for project stability. Only version 1.0.0 will be installed at install time.
format | define |
---|---|
1.0.0 | Lock version 1.0.0, which is required. |
^ 1.0.0: insert number | For example, we install the latest version of 1.x.x (at least 1.0.0), but we do not install 2.x.x, that is, we do not change the larger version number when we install. It is important to note that if the major version number is 0, the behavior of the insertion number is the same as that of the tilde. This is because at this stage of development, even minor version number changes can cause incompatibilities in the program. |
~ 1.2.2: wave number | Such as~ 1.2.2 , the latest version (not less than 1.2.2) of 1.2.x is installed, but 1.3.x is not installed, that is, the major and minor versions are not changed during installation. |
laster | Install the latest version |
1.5 devDependencies
Definition: Specifies the modules required for the development of the project
During your development process, you may want to introduce some third-party libraries to improve your development efficiency. Well-known third-party libraries such as WebPack, rollUp, Less, Babel, etc.
While we need them in development, we don’t need them at all when we pack them up and run them online. These libraries will go into devDependencies.
The following libraries are recommended to install into devDependencies:
- Unit test support (Mocha, CHAI);
- Syntax compatibility (Babel);
- Syntax conversion (JSX to JS, Coffeescript to JS, typescript to JS)
- Program construction and optimization (Webpack, gulp, Grunt, uglifyJS);
- CSS processor (postCSS, SCSS, Stylus);
- Code specification (ESLint);
1.6 peerDependencies
(peerDependencies) (NPM) (peerDependencies) (peerDependencies) (peerDependencies) (peerDependencies) (peerDependencies) (peerDependencies) (peerDependencies) (peerDependencies) (peerDependencies)
Since versions after NPM @>3 manage the package themselves, using peerDependencies avoids packaging different versions of the same library into the package. The following describes some inconsistencies.
1.6.1 version is consistent
If a package defines PackageB peerDependencies and I am listed as a dependency in project usage, then the project must also have PackageB dependencies.
That is, package does not package PackageB into compiled code when it is compiled and released, assuming that his project will install these dependencies.
You also want to avoid reinstalling third-party libraries multiple times and packaging different versions of third-party libraries when installing multiple plug-ins.
If the versions used are the same, the node_modules directory is displayed as follows.
1.6.2 Version inconsistency
If in the project
A uses B version 1.0
C uses version B 2.0
In this case, NPM will be placed in its own directory according to the installation sequence.
1.6.3 NPM Processing
- If the user explicitly relies on the core library, the plug-in’s
peerDependency
The statement; - If the user does not explicitly rely on the core library, follow the plug-in
peerDependencies
The declared version installs the library into the project root directory. - When the version that the user depends on and the version that each plug-in depends on are not compatible with each other, it seems that an error will be reported for the user to fix. (Here to be confirmed)
Npm2 will actively force the installation of dependency packages, but in NPM3, the generation of dependency trees will be as flat as possible, and the behavior of peerDependency will change accordingly. The dependencies declared in peerDependencies will not be installed automatically if the project does not have explicit dependencies installed. Instead, NPM will issue warning logs telling the project developer that you need explicit dependencies and that you need to stop relying on me.
1.6.4 Module Dependency Description
Source: github.com/minhuang0/n…
Only applicable to NPM3
How to handle dependencies in package.json when module A installs module B; The parent component replaces module A and the child component replaces module B
Node_modules: node_modules directory of module A
Child_node_modules: node_modules directory of module B. When module A installs module B, the directory becomes node_modules/child_modules_name/node_modules
Child dependencies
The module version of child component dependencies is installed in node_modules only when dependencies define modules.
Child devDependencies
The parent component does not install the module in the child devDependencies only when it defines the module in devDependencies.
Child peerDependencies
< p style = “max-width: 100%; clear: both; min-height: 1px; Incorrect peer Dependency), the module is not installed actively in the parent node_modules;
The Child devDependencies, peerDependencies
When the child module is defined in devDependencies and the version range is specified in peerDependencies, the parent component does not automatically install the module defined in the child devDependencies, but prompts for both waring
When the parent component dependencies and devDependencies do not have the module installed, the child component peer Dependency definition does not meet the following requirements:
warning "> [email protected]" has unmet peer dependency "[email protected]".
Copy the code
A message indicating that the module defined by the child component peer Dependency has an incorrect version of the parent component Dependencies or devDependencies installed
warning "> [email protected]" has incorrect peer dependency "[email protected]".
Copy the code
The Child dependencies, peerDependencies
When a child component defines a module in Dependencies and the version range is specified in peerDependencies, the parent component automatically installs the module defined in child dependencies, but there are three situations
- If the parent component dependencies and devDependencies do not define module dependencies, the parent component automatically installs module dependencies in node_modules.
warning "> [email protected]" has unmet peer dependency "[email protected]".
Copy the code
- When a module is defined for parent dependencies or devDependencies, and the module of the parent does not meet the module definition for child peerDependencies, Node_modules installs modules defined by parent dependencies or devDependencies, Install the module defined in dependencies in node_modules/children_modules/node_modules
warning "> [email protected]" has incorrect peer dependency "[email protected]".
Copy the code
- When a module is defined for parent dependencies or devDependencies, and the module of the parent satisfies the module definition for child peerDependencies, Node_modules installs modules defined by parent dependencies or devDependencies. This is the same as the module required by the child component;
conclusion
- There are two kinds of warring warnings when the parent component is not specified in the peerDependencies module (unmet peer dependency, peer dependency). Incorrect peer Dependency);
- Child components do not install node_modules and child_node_modules only when the devDependencies module is defined; When simultaneously defined in the peerDependencies module, the result is the same as above;
- The module definition of the child component in Dependencies tells the parent to install this configuration:
- When the module definition of parent component dependencies or devDependencies is the same as the module definition of child component dependencies, only a copy of the module is installed under node_modules.
- When the module definition for parent dependencies or devDependencies is different from the module definition for child dependencies, node_modules is used to install the module configured by the parent component. Install the version of the child component configuration in child_node_modules(see definition above);
- Subcomponents are defined in the dependencies module, and when defined in the peerDependencies module:
- When the parent’s module definition in Dependencies or devDependencies meets the child’s module definition in peerDependencies, only a copy of the module is installed under node_modules.
- There are two kinds of warring warnings when the parent component dependencies or devDependencies module definition does not meet the criteria for the child dependencies in peerDependencies. Incorrect: Incorrect peer Dependency). Install the parent module under node_modules, and install the child version in child_node_modules (see definition above).
1.7 bin
Definition: Provides command shorthand for scripts
"bin": {
"node": "./bin/node10"
}
Copy the code
This defines the node reference version 10 currently running in scripts.
1.8 the main
Definition: The main field specifies the entry file to load, and require(‘moduleName’) will load this file. The default value for this field is index.js under the module root.
1.9 the config
{
"config" : { "port" : "8080"}}Copy the code
You can use this in a Node project
http
.createServer(...)
.listen(process.env.npm_package_config_port)
Copy the code
1.10 brower
Definition: browser specifies the version of this template for browser use. A browser packaging tool like Browserify knows which file to package.
1.11 engines
Definition: The Engines field specifies the platform on which the module is running, such as a version of Node or a browser
{ "engines" : { "node" : "> = 0.10.3 < 0.12"}}Copy the code
Or specify the NPM version
{ "engines" : { "npm" : "~ 1.0.20"}}Copy the code
2. Pack
2.1 webpack
2.2 a Rollup
2.3 TSDX
3. Version revision
- The 2020-02-18 edition
4. Reference
Package. json
Javascript.ruanyifeng.com/nodejs/pack…
www.cnblogs.com/wonyun/p/96…
Nodejs.org/es/blog/npm…
Github.com/SamHwang199…
Github.com/minhuang0/n…
Semantic version:
semver.org/lang/zh-CN/