Detailed introduction to npm’s module installation mechanism

The logical structure of the dependency tree surface and the real physical structure of the dependency tree

The dependency tree surface The logical structure is not necessarily the same as the real physical structure of the dependency tree!

There are two commands to mention here: tree -d (linux) and npm ls (npm)

Under an npm project ：

tree -d commandList the physical structures of all dependencies under a project in a tree diagram

npm ls commandLists the logical structure of all dependencies under a project in a tree diagram

Take the official document as an example:

Project example1 has two dependent modules: mod-a module and mod-c module;

The mod-a module has a dependent module mod-b@1.0.0 module

The mod-c module has a dependent module mod-b@2.0.0 Module

tree -d and npm ls running results are as follows: (note that the npm version is npm3 instead of npm2)

# First look at the result of the red box below, this should be "most consistent We understand the dependency tree of ". First, the first-level dependency is formed under the project - mod-a module and mod-b module. Then these two modules are used as parent modules and the second-level dependency module mod-b@1.0 is added. .0 and mod-b@2.0.0

But! This is not what the physically formed dependency tree looks like. The physically formed dependency tree is the red box above. mod-a, mod-c and mod-b are actually the same level of dependencies.

You may ask, Why is such a dependency tree formed? Let me explain it below

[Note]: The following illustrations are all the physical structure of the dependency tree. Rather than a logical structure

A little guess about the npm module installation mechanism

When installing a module, there are two possible ways: Flat installation or Nested installation (this is just a guess and assumption)

Can we adopt a completely flat installation method? --cannot

Let’s take an example similar to the above: there are two dependent modules A and B under the project APP; A has a dependent module Cv1.0; and B also has a dependent module Cv2.0. Obviously, they cannot exist under the same node_modules at the same time. When installing, Due to the mechanism of npm, only one version of the dependent module can be installed, One of them will overwrite the other.

#But if we only install one version of the C dependent module, it may result in module A and Module B is not compatible

Based on the above reasons, npm2 chose Nested installation method——

Module installation mechanism under npm2

npm2 installs multi-level dependency modules using a nested installation method:

##Advantages and disadvantages

Advantages: Solve the problem of single version Incompatibility issues that exist at the time, Achieving multi-version compatibility

Disadvantages: may cause a large amount of redundancy of the same module# The problem of ## is as follows:

Taking the above example as an example, the following situation is also reasonable:

I also know by feeling that this is by no means a good phenomenon. So how can we reduce this module redundancy while achieving multi-version compatibility between dependencies? So npm3 made some improvements

The module installation mechanism under npm3:

The difference between npm3 and npm2 is mainly reflected in the installation of secondary modules:

npm3 will

"try to" Logically, the modules at a certain level are placed in the first level of the project in terms of physical structure. Specifically, I can summarize them into the following three situations:

1. When installing a certain second-level module, if the first

level

# is found ##There is no module with the same name, so put the second-level module on the first-level2. During installation For a certain second-level module, if it is found that the first level

has the same name and the same version of the module, thendirectly Reuse that module3. When installing a certain second-level module, if the firstlevel

is found

Modules with the same name but different versions, then can only be nested under its own parent module

This may be a little difficult to understand at first, so let’s look at the pictures and let’s talk!

Let’s talk about 1 first: When installing a certain second-level module, if it is found that the first-level module has not been For modules with the same name, put this second-level module on the first level

Let’s simplify the above example first: now there is only one under the project APP The first-level dependent module A has a second-level dependent module C below it, but when npm install, the dependent

## is installed under the project.

#The second-level module (C v1.0) in npm3, when there is no module with the same name in the first-level directory (node_modules) of the project, will be installed in the first-level directory, thus following its parent module A Same level. This is the reason why the logical structure and physical structure of the dependency tree at the beginning of this article are different.

That is to say:

In npm2, The logical structure of the dependency tree is the same as its physical structure

In npm3, the logical structure of the dependency tree is the same as its physical structure. Different

Let’s talk about 2 more: When installing a secondary module, if the first For modules with the same name and the same version at the level, we can directly reuse that module

Based on 1, we Restore the example of 1 back to the previous more complicated scenario: There are two dependent modules A and B under the project APP; A has a dependent module Cv1.0; and B also has a dependent module C v1.0 (two C The module version is the same)

For npm2, the two C packages are the same, causing the module Redundancy

In npm3, because the C module under module A is installed to the first level, this allows module B to be reused at the same level; and the name, version, All the same C modules

npm3 uses this method to partially solve the pain points (partially) of npm2

[Transition from 1, 2 to 3] I said at the beginning of this section: "npm3 will "try to" logically "All" level modules are placed in the first level of the project", I think you should understand to some extent after reading 1 and 2 "try your best" Yes, but I said "try your best", which also means that npm3 cannot put second-level dependencies on the first level.. For this, please see 3:

Finally, 3: When installing a certain secondary module, if the second Modules with the same name but different versions at one level can only be nested below their own parent module

In 2, the two C modules that A and B depend on are the same. But what if the versions of the two C modules are different? , the project npm install situation is as follows:

In npm3, because B and A require The dependent modules are different (the requirement under B is C of v1.0, and the requirement under A is C of v2.0), so B cannot reuse the C v1.0 module under A like in 2

(Seeing this, I think it should answer your doubts about the example at the beginning of the article. This example is almost exactly the same as that example)

After seeing this, you have a general understanding of the module working mechanism under npm2 and npm3, as well as the optimization of npm3 for npm2, but please think about this Question: Has npm3 optimized the module redundancy defects of npm2 to the extreme? ———The answer is No, please read below:

Actually: Module redundancy may still occur in npm3, because there is already a v1.0 C module in the first-level directory,So all v2.0 can only be installed as secondary dependency modules, so you will see the following situation

And in the special case shown in the picture above, npm3 and npm2 appear to have no difference

#【Transition】So is there any solution to this? Of course there is. When the C v1.0 module under A module is updated to C v2.0, we can "redirect" all C v2.0 secondary dependent modules to C v2.0 through npm dedupe The C v1.0 in the first-level directory

Use npm dedupe to remove redundant modules:

npm What did dedupe do? It can "redirect" any redundant second-level dependent modules that can be removed to first-level modules with the same name/version

Reference materials npm official document Section 2 (how npm works):

[Warm reminder]: Any popular blog is inferior to a heavy book and boring documents

【End】

Remember 10 small words every day, the important thing is Accumulate!

memory: memory Dependency: dependency constraints: constraints deploy: deployment parameter: parameter scope: scope

ecosystems: ecosystem prefix: prefix Prior: priority/before revoke: revoke

 

The above is the detailed content of Detailed introduction to npm’s module installation mechanism. For more information, please follow other related articles on the PHP Chinese website!