In-depth understanding of NPM mechanism

This article brings you an in-depth understanding of the NPM mechanism. It has certain reference value. Friends in need can refer to it. I hope it will be helpful to you.

When using NPM to install, package conflicts often occur (such as inconsistent versions of submodules of multiple main modules, etc.), resulting in various major or minor problems encountered during the development process. All the following contents will be introduced here:

1. Main NPM installation method
2. NPM package information query
3. NPM installation mechanism (main)

Installation & query command

NPM various installation methods

• #npm install packageName[@next | @versionNumber]

  Installed when no module is specified in node_modules (does not check the ~/.npm directory)
• ##npm install packageName - -f | -- force
  No matter whether a module has been installed or not, npm will
  force it to be reinstalled
• npm update packageName
  Install if the remote version is newer or the local version does not exist

NPM query service

NPM knows the latest version of each module through the registry query service.

• You can query the information of the corresponding module through
npm view packageName [version]
NPM installation mechanism

Enter the npm install command and type After pressing Enter, it will go through the following stages (taking npm 5.5.1 as an example):

1. Execute the preinstall of the project itself

If the current npm project is defined The preinstall hook will be executed at this time.

2. Determine the first-level dependency modules

The first thing you need to do is to determine the first-level dependencies in the project, that is,

dependencies

and ## Modules directly specified in the #devDependencies attribute (assuming no npm install parameters are added at this time). The project itself is the root node of the entire dependency tree

. Each first-level dependency module is a subtree under the root node. npm will start multiple processes from each first-level dependency. The module begins to gradually search for deeper nodes.

If the specified module already exists in the node_modules directory, it will not be reinstalled.

3. Get the module

Getting the module is aThe process of recursion

is divided into the following steps:

Get module information

• Before downloading a module, you must first determine its version. This is because package.json often contains semantic version (semver, semantic version)

  At this time, if there is information about the module in the version description file (npm-shrinkwrap.json or package-lock.json), get it directly Just
  • If not, get it from the warehouse (query to the registry). For example, the version of a package in packaeg.json is ^1.1.0, npm will go to the warehouse to get the latest version that conforms to the 1.x.x format.
  Get module entity.

• The previous step will get the compressed package address of the module (resolved field). npm will use this address to check the local cache. If it is in the cache, it will be taken directly. If not, it will be downloaded from the warehouse.

  Find the dependencies of this module

• If there are dependencies, go back to step 1, if not, stop.
4. Module flattening (dedupe)

What you get in one step is a complete dependency tree, which may include Lots of repetitive modules. For example, module A depends on loadsh, and module B also depends on lodash. Before npm3, installation was strictly based on the structure of the dependency tree, which resulted in module redundancy.

Starting from

npm3 version

, a dedupe process has been added by default. It will traverse all nodes and place the modules one by one under the root node, which is the first level of node-modules. When duplicate modules are found, they are discarded.

Here you need to define a duplicate module, which refers to the module name is the same and semver compatible

. Each semver corresponds to a permitted version range. If the permitted version ranges of two modules overlap, a compatible version can be obtained without having to have exactly the same version number. This allows more redundant modules to be removed during the dedupe process. .

For example, if the foo module under node-modules depends on lodash@^1.0.0, and the bar module depends on lodash@^1.1.0, then ^1.1.0 is a compatible version.

When foo depends on lodash@^2.0.0 and bar depends on lodash@^1.1.0, according to the rules of semver, there is no compatible version between the two. One version will be placed in node_modules and the other will remain in the dependency tree.

For example, suppose a dependency tree originally looked like this:
• node_modules
• -- foo
---- lodash@version1

-- bar

---- lodash@version2

Assuming that version1 and version2 are compatible versions, after dedupe it will become the following form:

node_modules

-- foo

-- bar

-- lodash (the retained version is the compatible version)

Assuming that version1 and version2 are incompatible versions, the subsequent versions are retained in the dependency tree:

node_modules

-- foo

-- lodash@version1

-- bar

---- lodash@version2

5 .Install module

This step will update node_modules in the project and execute the life cycle functions in the module (in the order of preinstall, install, postinstall).

6. Execute the project's own life cycle

If the current npm project has a hook defined, it will be executed at this time (in the order of install, postinstall, prepublish, and prepare).

The last step is to generate or update the version description file, and the npm install process is completed.

This article has ended here. For more other exciting content, you can pay attention to the JavaScript Video Tutorial column on the PHP Chinese website!

The above is the detailed content of In-depth understanding of NPM mechanism. For more information, please follow other related articles on the PHP Chinese website!