[summary] 1361- package JSON and package lock JSON relationship

Modular development is becoming more and more popular in the front end , Use node and npm It is very convenient to download the dependent modules required for project management .package.json It is used to describe the project and the module information that the project depends on .

that package-lock.json and package.json What is the relationship and connection ？

package.json

Management package

Everybody knows ,**package.json It is used to describe the project and the module information that the project depends on .**, It helps us manage the dependent packages in the project , Let us stay away from the hell of dependence .

adopt npm management , Use some simple commands , Automatic generation package.json, Installation package dependencies are determined by package.json To manage , We hardly have to think about them .

Semantic version control

First, let's learn about the of dependent packages Definition of version number

Version number consists of three parts ：major.minor.patch, The major version number . Sub version number . Patch version number .

for example ：1.2.3, Major version 1, minor 2, Patch 3.

• Patch The changes in represent bug fixes that do not destroy anything .

• minor The change of means that the new function will not destroy any content .

• Major version The change represents a major change that undermines compatibility . If the user does not adapt to major version changes , The content will not work properly .

How to specify the version of the installation dependent package

I believe everyone will experience , When we install some dependent packages , The version number will be preceded by ^ perhaps ~ The symbol of , What do these two symbols mean ？

~ Will match the latest minor version dependency package , such as ~1.2.3 Will match all 1.2.x edition , But not including 1.3.0

^ Will match the latest large version dependency package , such as ^1.2.3 Will match all 1.x.x My bag , Include 1.3.0, But not including 2.0.0

* Install the latest version of dependent packages , such as *1.2.3 Will match x.x.x,

So how to choose ？ Of course you can Specify a specific version number , direct writing 1.2.3, front There is no prefix , This is certainly no problem , But if you rely on the package to release a new version, you fix some small bug, Then you need to modify it manually package.json file ;~ and ^ Then we can solve this problem .

But we need to pay attention ^ The version update may be relatively large , Will cause project code errors , therefore It is recommended to use ~ To mark the version number , This ensures that there will be no major problems in the project , It can also ensure the small in the bag bug Can be repaired .

The version number is written *, This means installing the latest version of the dependency package , But the disadvantages are the same as above , May cause version incompatibility , Use with caution ！

The problem of relying on package installation in multiplayer development

After reading the designation of the version number above , We can know , When we use it ^ perhaps ~ To control the dependent package version number , Multi person development , There may be different versions of dependent packages installed by everyone , There will be different results of project operation .

Let's take an example ：

Suppose we have installed vue, When we run the installation npm install vue -save When , In the project package.json Of vue The version is  vue: ^3.0.0, Our computer is installed with vue The version is 3.0.0 edition , After we submit the project code , After a while ,vue New version released 3.0.1, Then a new colleague came , From the new git clone Cloning project , perform npm install During installation , On his computer vue The version is 3.0.1 了 , because ^ Just locked the main version , In this way, in our computer vue The version will be different , In theory （ If everyone follows semantic version control ）, They should still be compatible , But maybe bugfix It will affect the functions we are using , And when using vue edition 3.0.0 and 3.0.1 Runtime , Our application will produce different results .

Let's think , In this case , Dependent version projects installed on different personal computers , Is it possible that they are different , It will cause everyone's application running on the computer to produce different results . There will be bug The hidden danger of .

At this time, some students may think of , So we're in package.json Just lock the version number of the dependent package on it ? direct writing vue: 3.0.0 Lock up , In this way, everyone can install vue The versions of are 3.0.0 Version of the .

This idea is certainly good , But you can only control your own project lock version number , What about the dependent packages in your project ？ How do you control and restrict others to lock the version number ？

In order to solve this problem, all dependent versions installed on different human computers are consistent , Make sure that the project code runs the same during installation , At this time package-lock.json And that's what happened .

package-lock.json

package-lock.json Is in npm(^5.x.x.x) Only later , There are several changes in the middle

Introduce

This is how the official document explains ：package-lock.json It will stay npm change node_modules Directory tree perhaps package.json Automatically generated when , It accurately describes the current project npm The dependency tree of the package , And it will be installed according to package-lock.json To install , The guarantee is the same as a dependency tree , Regardless of whether there is a dependency with a minor version update in the process .

It is produced to fix the version of the whole dependency tree （ Lock up ）.

When we're in a project npm install When , It will automatically generate a package-lock.json file , and package.json In the same directory .package-lock.json It records some information of the project and the modules it depends on . In this way, the same results will appear in each installation . No matter what machine you install it on or when .

When we next npm install When ,npm It is found that if there is package-lock.json file , Will be based on package-lock.json To process and install dependencies based on the contents of the package.json.

Be careful , Use cnpm install When , It doesn't generate package-lock.json file , Nor will it be based on package-lock.json To install dependent packages , Still use package.json To install .

package-lock.json Generative logic

Briefly describe package-lock.json The logic of generation . Suppose we now have three package, In the project lock-test in , Installation dependency A,A The project surface has B,B The project surface has C

// package lock-test
{ "name": "lock-test", "dependencies": { "A": "^1.0.0" }}
// package A
{ "name": "A", "version": "1.0.0", "dependencies": { "B": "^1.0.0" }}
// package B
{ "name": "B", "version": "1.0.0", "dependencies": { "C": "^1.0.0" }}
// package C
{ "name": "C", "version": "1.0.0" }
 Copy code 

under these circumstances package-lock.json, It will generate a structure similar to the one below

// package-lock.json
{ 
    "name": "lock-test",  
    "version": "1.0.0",  
    "dependencies": {    
        "A": { "version": "1.0.0" },
        "B": { "version": "1.0.0" },
        "C": { "version": "1.0.0" }  
    }
}
 Copy code 

If the follow-up is directly dependent A release , Or indirectly B, C release , As long as we don't move package.json, package-lock.json Will not regenerate .

A New version released 1.1.0, Although we package.json Is written ^1.0.0 But because package-lock.json The existence of ,npm i It doesn't automatically upgrade ,

We can run it manually npm i [email protected] To upgrade .

because 1.1.0 package-lock.json Recorded in [email protected] It's inconsistent , So it will be updated package-lock.json Inside A The version is 1.1.0.

B New version released 1.0.1, 1.0.2, 1.1.0, At the moment, if we don't do the operation, we won't automatically upgrade B The version of the , But if at the moment A Released 1.1.1, Although not upgraded B Dependence , But if we upgrade in the project [email protected]1.1.1, here package-lock.json I will put B Go straight up to 1.1.0 , Because now ^1.0.0 The latest version of is 1.1.0.

After these operations project lock-test Of package.json become

// package 
lock-test{ "dependencies": { "A": "^1.1.0" }}
 Copy code 

Corresponding package-lock.json file

{  
    "name": "lock-test",  
    "version": "1.0.0",
    "dependencies": {  
        "A": { "version": "1.1.0" },
        "B": { "version": "1.1.0" },
        "C": { "version": "1.0.0" }
    }
}
 Copy code 

At this time we will B Join us lock-test Project dependency , [email protected]^1.0.0,package.json as follows

{ "dependencies": { "A": "^1.1.0", "B": "^1.0.0" }}
 Copy code 

After we do this ,package-lock.json It hasn't changed , Because now package-lock.json in [email protected] Satisfy ^1.0.0 The requirements of

But if we will B The version of is fixed to 2.x edition , package-lock.json It will change

{ "dependencies": { "A": "^1.1.0", "B": "^2.0.0" }}
 Copy code 

Because there are two conflicting B edition ,package-lock.json The file will take the form of

{  
    "name": "lock-test",
    "version": "1.0.0",  
    "dependencies": {    
        "A": {      
            "version": "1.1.0",      
            "dependencies": {        
                "B": { "version": "1.1.0" }      
            }    
        },    
        "B": { "version": "2.0.0" },    
        "C": { "version": "1.0.0" }  
    }
}
 Copy code 

because B There is a conflict in the version of ,npm Nesting is used to describe this behavior

We don't need to pay attention to the generated algorithm logic in actual development , We just need to understand ,package-lock.json The logic of generation is to accurately reflect our node_modules Structure , And ensure that this structure can be restored .

package-lock.json Possible reasons for unexpected changes

1. package.json The file has been modified

2. Moved the bag

Move part of the package from dependencies Move to devDependencies Such operation , Although the package has not changed , But it can also affect package-lock.json, I'll pack some of them dev Field set to true

1. registry Influence

It was found through practical use that , If we node_modules When downloading from the package under the folder , Even if the version is the same , Install source registry Different , perform npm i It will also be modified when it is used package-lock.json

There may be other reasons , however package-lock.json It won't be changed for no reason , It must be because package.json perhaps node_modules Has been changed , because As mentioned above package-lock.json In order to accurately reflect us node_modules Structure

Suggestions for development

In general npm install Yes. , He can guarantee that according to package-lock.json Restore the development of node_modules.

But in order to prevent the accidents just mentioned , Except when it comes to adjusting the package , In other cases, it is recommended to use npm ci To install dependencies , Will avoid abnormal modification package-lock.json,

It is more recommended to use npm ci, Guarantee Accuracy of the build environment ,npm i and npm ci The difference between Please refer to the official documents npm-ci

Reference article ：

my package-lock.json Who changed it ？

npm install Generated package-lock.json What file is it ？ What's the usage? ？

author ： Aliwang  

link ：https://juejin.cn/post/7078233610683170824