package- lock.json and yarn.lock Is your best friend


package- lock.json and yarn.lock Is your best friend

Why keep them and when to abandon them?

Have you ever encountered and thought about the following problems?

  • What is a package- lock.json (or yarn.lock )?
  • Why do we need it?
  • My package- lock.json There is a conflict in the file
  • I ignore it when I submit
  • I’m going to delete it

Worse, you may have deleted it and submitted your PR or push to the master!

If this is the case, you have modified itMuch larger than expectedSource code.

You can control your own source code, but package- lock.json and yarn.lock The file ensures that your third-party code does not change between two commits

Treat third party packages as first-class citizens

It is important to understand this when unlocking the secrets of the package lock file. Many developers only consider changing their own source code, but third-party code installed through package managers such as NPM and yarn is equally important, or even more.

Why? Because they lead to bugs that are hard to trace.

In other words, without the package lock file, you don’t know what’s going on in the code, resulting in bugs that you might have observed. You might stare at the code differences between commits and spend hours thinking that these changes are unlikely to cause this problem.

You’re right. It’s code you can’t see that’s causing the problem.

Give your third-party packages due respect and treat them as your own code.

Think of your package as binary code for a project submitted to you by multiple developers as if it were open source

Let’s address the above points.

What is a package lock file? Comparison of fruits and vegetables

package- lock.json and yarn.lock Is your best friend

Think about it. You like fruits and vegetables. You need to buy fruits and vegetables every week, so you have a standard shopping list that rarely changes:

Weekly shopping list:


Now, you actually like certain kinds of fruits and vegetables, so you want to make the list more specific:

Weekly shopping list:


You know your taste is a little better than this, so you add some details about each fruit and vegetable:

Weekly shopping list:

    Apple: Red
    Grape: Green
    Tomato: red
    Onions: white, red or brown
    Potatoes: washed or peeled
    Pumpkin: any kind

OK, we have a list, and it’s quite detailed, but there’s still room for change in some of our fruits and vegetables. So we went out and bought the items on the list and finally got a receipt:

Receipt - 01 / 01 / 2020

Apple Fuji
Tomato - red
Grapes - Green
Onion - Brown
Potatoes - wash
Pumpkin - origin

See what’s going on here? Although we did not specify the exact types of some fruits and vegetables, we had to buy the exact types.

Now, when we get home, eat our apples, cook all our vegetables, we are very happy with our choices, so we keep the receipt and take it with us next time we go shopping, along with our list.

Because we have a receipt that lists the items we bought last week, we bought exactly the same items this week.

This may continue, but suppose our taste for Apple has changed, so we wrote a new list:

Weekly shopping list

    Apple: Green
    Grape: white
    Tomato: red
    Onion: white, red or brown
    Potatoes: washed or peeled    
    Pumpkin: any kind

Now, when we go shopping, we will have to buy some kind of green apple. At the time of settlement, we received the following receipt:

Receipt - 02 / 01 / 2020

Apple - Southern Green Apple
Tomato - red
Grapes - Green
Onion - Brown
Potatoes - wash
Pumpkin - origin

We have bought exactly the same thing as last week, except that our apple has been replaced by southern green apple!

Because we keep receipts, we are able to remember all the fruits and vegetables we like and continue to buy the same ones.

But what if we throw away the receipt? We have to start from scratch and maybe end up with fruits and vegetables we don’t like.

Get it shopping lists, receipts, fruits and vegetables, but this is an article about software engineering?

Let’s go back to software:

  1. The shopping list represents yourpackage.jsonfile
  2. Each fruit and vegetable represents a package
  3. The type of fruit or vegetable represents the exact version of the package or the range of acceptable versions
  4. The receipt represents yourpackage-lock.jsonoryarn.lockfile

When we save the receipt, our package lock file, we are able to ensure that we get the same version of the package until our shopping list, which is ourpackage.jsonThe file has changed.

If we lose the package lock file, it is likely that the final package will not be what we expected.

Package lock file keeps commit unchanged

If the commit graph is opened in the selected version control tool, each cusp on the graph represents a version of the code. If the version of the code is pulled immutable, it should be the same no matter who and when it is retrieved.

If your code base contains dependentpackage.jsonDocuments, notpackage-lock.jsonoryarn.lockThis is not the case with a file (or another file used by other package managers to lock the package version). If we visit the commit at different times, we can get different versions of the package.

This is because new versions of the package have been released all the time, and we have allowed differences in some versions that we will accept. For example:

  "name": "my-angular-app",
  "version": "1.0.0",
  "scripts": {
    "ng": "ng",
    "start": "ng serve",
    "build": "ng build",
    "test": "ng test",
    "lint": "ng lint",
    "e2e": "ng e2e"
  "private": true,
  "dependencies": {
    "@angular/animations": "^8.2.1",
    "@angular/common": "^8.2.1",
    "@angular/compiler": "^8.2.1",
    "@angular/core": "^8.2.1",
    "@angular/forms": "^8.2.1",
    "@angular/http": "^8.0.0-beta.10",
    "@angular/platform-browser": "^8.2.1",
    "@angular/platform-browser-dynamic": "^8.2.1",
    "@angular/router": "^8.2.1",
    "core-js": "^2.5.4",
    "csstype": "^2.5.8",
    "ng2-file-upload": "^1.3.0",
    "rxjs": "~6.5.3",
    "zone.js": "~0.9.1",
    "typescript": "~3.5.0"
  "devDependencies": {
    "@angular-devkit/build-angular": "~0.803.19",
    "@angular/cli": "^8.3.19",
    "@angular/compiler-cli": "^8.2.1",
    "@angular/language-service": "^8.2.1",
    "@nguniversal/express-engine": "^7.0.2",
    "@types/jasmine": "~2.8.8",
    "@types/jasminewd2": "~2.0.3",
    "@types/node": "~8.9.4",
    "codelyzer": "~4.5.0",
    "jasmine-core": "~2.99.1",
    "jasmine-spec-reporter": "~4.2.1",
    "karma": "~3.0.0",
    "karma-chrome-launcher": "~2.2.0",
    "karma-coverage-istanbul-reporter": "~2.0.1",
    "karma-jasmine": "~1.1.2",
    "karma-jasmine-html-reporter": "^0.2.2",
    "protractor": "~5.4.0",
    "ts-node": "~7.0.0",
    "tslint": "~5.11.0"

Pay attention to all of themand^Is that right? If these packages are installed at different times, different versions of these packages may be downloaded.

although package.json There are differences in the file, but the package is reserved- lock.json or yarn.lock The file will lock these versions.

I’m going to let some numbers speak,yarnAfter initial installation,node_modulesThe size and number of files in the folder

package- lock.json and yarn.lock Is your best friend

deletenode_modulesAnd re install the file size and number, keepyarn.lock

package- lock.json and yarn.lock Is your best friend

deletenode_modulesAnd re install, removeyarn.lockFile size and number after

package- lock.json and yarn.lock Is your best friend

The above detailed surface is deletednode_modulesAfter the package is re installed,node_modulesNo changes have taken place in the folder.

However, in the deletionnode_modulesFolder andyarn.lockAfter the files, there are 1507 files, and their total size exceeds7mb

What are these extra files, and will some of them get into the running code of our application? The terrible thing is that we may never know.

Delete or not submit your package- lock.json Or yarn.lock It’s like “submit my code and randomly modify x% of the rest of our source code.”

Is it safe to remove package locks?

Have you ever made a major refactoring across a large number of unrelated functions on your code base? Maybe you intentionally updated the main library, such as the front-end framework. You are not sure what, if anything, might break down, so you run a complete regression test on your application?

Well, if you want to remove the package lock file, I might suggest that you do the same.

If changing a large cross section of your code causes you to run a full regression test, you should also change a large proportion of your third-party code

If you really want topackage.jsonFile access to the latest and best software packages (alland^Can be updated to the latest patch and minor version).

Deleting a package lock file may take advantage of package.json File is a good way to be powerful, but be prepared to run full regression tests or resolve any unexpected behavior


Except in some extreme cases, NPM packages will not be deleted and any given version will not be modified. They are immutable.

For any given commit, your own code should also be immutable if used by the Yale usernpmoryarn.lock, the mechanism that allows this is calledpackage-lock.jsonDocuments.

The existence of this file ensures that the same package version is installed for a given commit, so your own source code and third-party packaged code are the same no matter who uses it and when.

Deleting or not submitting these files can lead to unpredictable behavior of the application, because the actual installed version of the package may change over time for the same commit, and if errors are found to be caused by the wrong package, it may be difficult to trace them.

Therefore, it is recommended that you submit these files without deleting them, unless you intend to do so under thepackage.jsonThe specification updates the software package and is ready for thorough testing or rapid repair of all errors found in production.

Thank you for your reading. I hope that explainspackage-lock.jsonandyarn-lock.jsonDocuments.

Related links:

  • package-lock
  • yarn-lock

Focus on the big front-end technology and the growth of programmers. If you have inspiration and help, you can pay attention to it, collect it, or leave a message for discussion. This is the greatest encouragement to the author.

Author profile: Web front-end engineer, full stack development engineer, continuous learner.

package- lock.json and yarn.lock Is your best friend