This is an article without code

DESC

Since upgrading to 5.x, when downloading NPM packages, adding package.json also adds a package-lock.json, so what is it? What does he use it for? So I went to the official document and translated it.

Package-lock. json is automatically generated for any NPM modification of node_modules or manual modification of package.json. It describes the dependency tree generated so that subsequent installments download the same version of the package, regardless of whether the corresponding package is updated in the meantime.

Package-lock. json locks the version number of the installation to ensure that the download dependency of other people’s NPM install is maintained.

So? Why would you do that? We need some background before we can do that.

Version control

Normally, now we develop and build a program, we will download a variety of required toolkit, each package has a corresponding version number, a version number consists of three parts, X, Y, Z, respectively is the major version number, minor version number, patch version number. For example, node Current is 16.3.0, so major is 16, minor is 3, and patch is 0.

Convention has it that a change in a patch release means a bug fix that doesn’t break anything, a change in a minor release means an update to a new feature that doesn’t break any existing functionality, and a major release change means a major change that significantly breaks compatibility.

So you can understand what the father of Python said recentlyPython 4.0 May not be coming. Big releases mean big changes, big learning, and necessary conditions.

Package management

NPM was created in part to make it easier to manage packages in a project, where we download hundreds of packages and each package has n dependencies, so node_modules inevitably become heavy and cumbersome. To make it easier to manage these packages, NPM adds a semantic version to the package when it installs a package, including the package name and version number. For example, if we install dayjs, NPM I dayjs-s. package inserts a key-value pair, “dayjs” : “^1.10.5”, which means we are at least using the dayJS version above 1.10.5, but major version 1 cannot be changed.

Collaborative development && sharing of projects

The benefit of showing the dependencies needed in the project and their version numbers in package.json is that any dependencies downloaded into the project are logged there for unified management, but there is another problem.

For example, the dayJS package we just downloaded is 1.10.5. At this time, the maintainer who developed DayJS released an incorrect version 1.10.6, and a new colleague ran NPM install in the code folder. Since dayJS has a higher version of the same main version, So the version downloaded in the project at this point is 1.10.6. In theory, there is no conflict between the two versions, but you’ll notice at this point.

Your new colleague’s code doesn’t work, but yours does.

So you look at him out of the corner of your eye.

package-lock

Package-lock is designed to prevent this from happening, so you’ll find that package-lock.json is generated when you install the package, unless you disable it.

Package-lock. json lists the details of each of our dependencies, such as the particular version that should be installed, the URI of the module, the required dependencies list, the package list, and so on, using Express as an example.

 "express": {
      "version": "4.17.1"./ / version number
      "resolved": "Https://registry.nlark.com/express/download/express-4.17.1.tgz?cache=0&sync_timestamp=1618847120573&other_urls=https%3A % 2 f%2fregistry.nlark.com % 2 fexpress % 2 fdownload % 2 fexpress - 4.17.1..tgz".// The module's location URI
      "integrity": "sha1-RJH8OGBc9R+GKdOcK10Cb5ikwTQ=".// Verify the integrity of the module hash
      "requires": {  // List of packages it depends on
        "accepts": "~ 1.3.7." "."array-flatten": 1.1.1 ""."body-parser": "1.19.0"."content-disposition": "0.5.3"."content-type": "~ 1.0.4." "."cookie": "0.4.0"."cookie-signature": "1.0.6"."debug": "2.6.9."."depd": "~ 1.1.2"."encodeurl": "~ 1.0.2"."escape-html": "~ 1.0.3"."etag": "~, version 1.8.1"."finalhandler": "~ 1.1.2"."fresh": "0.5.2"."merge-descriptors": "1.0.1"."methods": "~ 1.1.2"."on-finished": "~ 2.3.0." "."parseurl": "~ 1.3.3." "."path-to-regexp": "0.1.7"."proxy-addr": "~ at 2.0.5." "."qs": "6.7.0"."range-parser": "~ 1.2.1." "."safe-buffer": "5.1.2"."send": "0.17.1"."serve-static": "1.14.1"."setprototypeof": 1.1.1 ""."statuses": "~ 1.5.0." "."type-is": "~ 1.6.18"."utils-merge": "1.0.1"."vary": "~ 1.1.2"
      },
      "dependencies": { // List of dependent package details
        "debug": {
          "version": "2.6.9."."resolved": "Https://registry.nlark.com/debug/download/debug-2.6.9.tgz?cache=0&sync_timestamp=1618847042350&other_urls=https%3A%2F%2 Fregistry.nlark.com % 2 fdebug % 2 fdownload % 2 fdebug - 2.6.9..tgz"."integrity": "sha1-XRKFFd8TT/Mn6QpMk/Tgd6U2NB8="."requires": {
            "ms": "2.0.0"}},"ms": {
          "version": "2.0.0"."resolved": "https://registry.nlark.com/ms/download/ms-2.0.0.tgz"."integrity": "sha1-VgiurfwAvmwpAd9fmGF4jeDVl8g="}}},Copy the code

With the above information, NPM uses package-lock.json instead of package.json to install packages. In this case, we can ensure that the corresponding packages installed in the project and corresponding dependencies in the package are unified in the case of collaborative development.

Problems arising

Package-lock. json is ambiguous when it is added, and most of the NPM content we can search for about package-lock.json is about disabled content.

Before package-lock was added, we used package.json as the information content of the package. When we introduced package-lock.json, NPM used package-lock.json as a benchmark for downloading packages, which caused some problems:

  1. For example, if we install express package 4.17.1, and then we want to install a lower package, such as 4.16.1, we will definitely change the package.json to 4.16.1, and then delete node_modules. NPM will install the 4.17.1 express package

  2. For example, when we accidentally deleted package contents of package-lock.json, the package.json contents also contained the information of those packages, so we NPM install, and then found that the project could not run, we found various problems, and my old colleague told you, You can delete node_modules and package-lock.json and install NPM again.

And then you try it, and it works, and the great god is the cow.

.

For the above problems, NPM releases updates in v5.10. If the user updates the contents of package.json package, the locked package version corresponding to package-lock.json will not take effect, and the package.json package version will be used for modification. Add the version of the currently downloaded dependencies and other information to package-lock.json.

At the same time, we believe that when we find that our own project cannot run, while our colleague’s can run, one way to check is to find the location of the package reporting error, see the version number, and compare it with the local one to see whether it is consistent.

Reference documentation

www.cnblogs.com/dreamsqin/p… Medium.com/coinmonks/e… www.npmjs.cn/files/packa…