【 原文 原文 】

Antecedents feed

When you happily upgrade NPM to V5.X. x(sic times), everything seems to be going well. Aye… Wait, a new file has been created automatically! What is this? Package – lock. Json. If you browse through it, you’ll see that it looks similar to package.json dependencies, but much longer. Leave it alone, you think, but you end up with all sorts of problems with dependencies that have the wrong version installed or dependencies that can’t be found. Many people’s solution is to delete package-lock.json and run NPM install again. If so, what is the point of package-lock.json? What is its purpose to solve?

An overview of

  • If you are using NPM 5.0.0 or higher, package-lock.json will be created automatically.
  • Package-lock is used to ensure stable installation and dependency compatibility.
  • To ensure source consistency, you must commit the package-lock file.
  • In NPM 5.1.x and above, package.json has more weight than package-lock.json, which solves a major headache.
  • No need to manually delete the package-lock file and then NPM install to regenerate it.
  • Use and follow semver semantic versions.

background

Semantic version

Before you can explore package-lock, you must understand Semver. It is the minor hero behind NPM. You can see how NPM uses it here. In general, if you are developing an application that can be used by other applications, you must explain how each update will affect third party use. This is what the semantic version is trying to convey. A release has three parts: X, Y, and Z, which refer to the major release, minor release, and missing release respectively. For example, 1.2.3 would be big version 1, small version 2, Bugfix version 3. The Bugfix version does not affect any functionality, and minor version changes often add new functionality and do not affect usage. Large version changes often lead to usage level incompatibilities that require further adjustments. (Think about webPack every time you upgrade!)

Package management

It was to make package management easy that NPM came along. A project may have hundreds of dependencies, and each dependency has hundreds of dependencies. To save you from dependency hell, NPM can install and manage these dependencies with just a few lines of command, saving a lot of time.

When you install (and save) a package using NPM, package.json automatically adds a message, including the package name and its version. NPM also supports version wildcards. NPM installs the latest version by default, and then prefixes its version number with a “^” character. For example, “^1.2.12” indicates that a minimum version of 1.2.12 should be used, and above that, any version with the same large version number is OK. After all, the smaller and Bugfix versions don’t affect usage at all, so it’s safe to use any more advanced version of the same size. Learn more about semver wildcards and NPM’s Semver calculator here.

Many projects

The real benefit of package. json is that anyone can use this file to generate a folder with all the dependencies a project needs. But let’s see, what could go wrong?

Let’s create a new project that uses Express. After executing NPM init, install Express: NPM install Express -save. The highest version of Express was 4.15.4 when I wrote. So “Express” : “^4.15.4” is written to package.json and dependencies are already loaded. The next day, however, maybe the maintainer of Express released a Bugfix version, so the latest version was 4.15.5 again. If my colleague clone the project at this point and execute NPM install, he will install the latest 4.15.5 since the major version of 4.15.5 has not changed. We all have Express installed, but different versions. In principle, they are compatible with each other, but it may happen that the fixed bugfix affects the functionality we use, and we run our own projects with different results. That’s a problem!

Package-lock

The target

Package-lock is designed to solve these problems! This means that different results may be installed from the same package.json file. Package-lock.json was added since NPM 5.x.x, so it will be generated automatically as long as you don’t disable it.

format

Package-lock includes the installed version of the Package illustrated in package.json, the installation address (URI), a hash to verify Package integrity, its required subpackages, and a dependency list. The package-lock entry for Express is as follows:

"express": {
      "version": "4.15.4"."resolved": "https://registry.npmjs.org/express/-/express-4.15.4.tgz"."integrity": "sha1-Ay4iU0ic+PzgJma+yj0R7XotrtE="."requires": {
        "accepts": "1.3.3"."array-flatten": 1.1.1 ""."content-disposition": "0.5.2"."content-type": "1.0.2"."cookie": "0.3.1"."cookie-signature": "1.0.6"."debug": "2.6.8"."depd": 1.1.1 ""."encodeurl": "1.0.1"."escape-html": "1.0.3"."etag": "1.8.0 comes with"."finalhandler": "1.0.4"."fresh": "0.5.0"."merge-descriptors": "1.0.1"."methods": 1.1.2 ""."on-finished": "2.3.0"."parseurl": "1.3.1"."path-to-regexp": "0.1.7"."proxy-addr": "1.1.5."."qs": "6.5.0"."range-parser": "1.2.0"."send": "0.15.4"."serve-static": "1.12.4"."setprototypeof": "1.0.3"."statuses": "1.3.1"."type-is": "1.6.15"."utils-merge": "1.0.0"."vary": 1.1.1 ""}},Copy the code

Each package that requires has the same entry under package-lock.

So NPM actually now uses package-lock.json to determine how dependencies are installed! Because package-lock specifies the installed version of the package, the address, the package integrity check, and all the child dependencies of the package, installing the module according to package-lock will get exactly the same result.

debate

If packge-Lock is designed to solve problems, why is there so much skepticism about its existence and discussion about how to disable its generation?

Before nPM5.x. x, package.json was the only source of truth for a project. Package. json means what it says! NPM consumers like and are used to maintaining only package.json. But when package-lock came along, it did the opposite of what many expected! If there is the same package and package-lock, package.json changes do not affect package-lock.

The package.json change does not take effect after installation, and package-lock needs to be removed to regenerate, which causes a lot of controversy. Take a look at this interesting reop timeline. Some people think that package.json will prevail, while others think that since package-lock has been created, it will prevail. The final argument ends with PR#17508. NPM decides that package.json will be given more weight than package-lock at install time if changes have been made to package.json. This decision comes with THE release of NPM V5.1.0, effective from July 5, 2017