Why should they be kept and when should they be discarded?

Have you encountered and considered the following questions?

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

Even worse, you might have deleted it and submitted your PR or push to Master!

If this is the case, you have modified a much larger source code than you expected.

You can control your own source code, but package-Lock. json and yarn.lock files ensure that your third-party code doesn’t change between commits

Treat third-party packages as first-class citizens

Understanding this is crucial when unlocking the secrets of a locked file. Many developers only consider changing their own source code, but third-party code installed through package managers such as NPM and YARN is just as important, if not more so.

Why is that? Because they lead to bugs that are hard to track.

In other words, without the Package Lock file, you wouldn’t know what had changed 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 could not have caused this problem.

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

Treat your third-party packages with the respect they deserve and treat them as your own code.

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

Let’s address these points.

What is the Package Lock file? Fruit and vegetable metaphor

Think of it this way: you love 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: Fruits and vegetablesCopy the code

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

Weekly shopping list: Fruits apples grapes tomatoes vegetables Onions potatoes pumpkinsCopy the code

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

Weekly Shopping List: Fruit Apple: Red Grapes: Green Tomato: Red Vegetable Onion: white, red or brown Potato: Washed or shaved Pumpkin: Any kindCopy the code

Well, we have the list, and it’s quite detailed, but there’s some room for variation with some of our fruits and vegetables. So we went out and bought the things on the list and ended up with a receipt:

Receipt - 01/01/2020 Apples - Fuji Tomatoes - Red Grapes - Green Onions - Brown Potatoes - Washed Pumpkins - OriginCopy the code

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

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

Because we have receipts that list the items we bought last week, we bought exactly the same items this week.

This could go on and on, but let’s say our taste for apples changes, so we write a new list:

Weekly Shopping list Fruit: Apple: Green grapes: White Tomato: Red vegetable: Onion: white red or brown Potatoes: Washed or shaved pumpkin: AnyCopy the code

Now, when we go shopping, we’re going to have to buy some kind of green apple. At settlement, we got the following receipt:

Receipt - 02/01/2020 Apples - Southern Green Apple Tomatoes - Red grapes - Green Onions - Brown Potatoes - Washed pumpkins - OriginCopy the code

We have purchased exactly the same thing as last week, except our apples have been changed to southern green apples!

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 receipts? We have to start from scratch and may end up with fruits and vegetables we don’t like.

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

Let’s go back to the software perspective:

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

When we save the receipt, which is our package Lock file, we are able to ensure that we get a version of the same package until our shopping list, which is our package.json file, changes.

If we throw away the package lock file, we are likely to end up with a package that is not what we expected.

The package locks the file to keep the commit intact

If the commit diagram is opened in the version control tool of your choice, each dot on the diagram represents a version of the code, and if the version of the code being retrieved (pull) is immutable, it should be the same no matter who retrieves it and when.

This is not the case if your code base contains package.json files with dependencies, rather than package-lock.json or yarn.lock files (or another file used by some other package manager to lock the version of the package). If we access the commit at different times, we can get different versions of the package.

This is because new versions of packages are released all the time, and we have allowed for differences in some of the versions we will accept. Such as:

{
  "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": 10 "" ^ 8.0.0 - beta.."@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": "~ 2"."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"}}Copy the code

Notice all the ~ and ^? Installing these packages at different times may result in downloading different versions of these packages.

Although there are differences in package.json files, keeping package-lock.json or yarn.lock files locks these versions.

I’ll let some numbers do the talking, the size and number of files in the node_modules folder after yarn is initially installed

Delete node_modules and reinstall the file size and number, and keep yarn.lock

Delete node_modules and reinstall, delete the file size and number after yarn.lock

The node_modules folder does not change after the node_modules is removed and the package is reinstalled.

However, after removing the node_modules folder and the yarn.lock file, there are 1507 files that total more than 7MB in size.

What are these extra files, and do some of them end up in our application’s running code? The scary thing is we may never know.

Removing or not committing your package-lock.json or yarn.lock is like saying “committing my code and randomly modifying X% of the rest of our source code”

Is it safe to remove package locks?

Have you ever done a major refactoring on a code base that spans a large number of unrelated functions? Maybe you intentionally updated a major library, such as a front-end framework, and you weren’t sure what, if anything, might break, so you ran a full regression test on your application?

Well, if you were deleting a package lock file, I might suggest you follow the same steps.

If changing a large cross-section of your code would cause you to run a full regression test, then you should also change a large percentage of your third-party code

If you really want to get the latest and greatest packages from the package.json file (all ~ and ^ can be updated with the latest patches and minor versions), you can remove the package lock file.

Removing package lock files can be a good way to take advantage of the power of package.json files, but be prepared to run full regression tests or resolve any unexpected behavior

conclusion

NPM packages are not deleted and any given version is not modified, except in some extreme cases. They are immutable.

Your own code should also be immutable for any given commit, and if NPM or yarn.lock is used for Yarn users, the mechanism that allows this is called package-lock.json files.

The existence of this file ensures that the same version of the package 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 committing these files can cause the application to behave in an unpredictable way, 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, they may be difficult to track down.

Therefore, it is recommended that you commit without deleting these files, unless you intend to update the package according to the package.json specification and are prepared to do a thorough test or quickly fix any bugs found in production.

Thanks for reading, I hope this explains the package-lock.json and yarn-lock.json files.

Related links:

  • package-lock
  • yarn-lock

Original text: levelup.gitconnected.com/package-loc…

Translation: Dunizb

Concern about the public number: “front-end foreign language selection”, to send high-quality video tutorial gift package!