LinuxCommandLibrary
GitHubF-DroidGoogle Play Store

package-lock.json

npm-generated lockfile pinning the exact installed dependency tree

TLDR

Note: package-lock.json is a generated file, not an executable command. The commands below operate on it.Create or update the lock file based on package.json
$ npm install
copy
Clean install from lock file (fails if lock file is out of sync; used in CI)
$ npm ci
copy
Update a specific package and rewrite the lock file
$ npm update [package]
copy
Audit the exact versions in the lock file for known CVEs
$ npm audit
copy
Inspect changes to the lock file in a diff
$ git diff package-lock.json
copy
Regenerate the lock file from scratch
$ rm package-lock.json && npm install
copy

SYNOPSIS

package-lock.json - npm dependency lock file (placed in the project root)

DESCRIPTION

package-lock.json is automatically generated by npm to describe the exact tree of dependencies that was installed. It records every resolved version, the registry URL, and an integrity hash (SRI), so subsequent installs produce the same node_modules regardless of which semver range the manifest allows.The file should be committed to version control. In CI, use npm ci instead of npm install: npm ci installs directly from the lock file without touching it, fails fast if it drifts from package.json, and is significantly faster.

KEY FIELDS

$ {
  "name": "my-project",
  "lockfileVersion": 3,
  "packages": {
    "": { "dependencies": {...} },
    "node_modules/lodash": {
      "version": "4.17.21",
      "resolved": "https://registry.npmjs.org/...",
      "integrity": "sha512-..."
    }
  }
}
copy

LOCK FILE VERSIONS

$ v1 - npm 5-6
v2 - npm 7+ (backwards compatible)
v3 - npm 7+ (optimized)
copy

CAVEATS

Do not edit by hand. Always commit it to git. Merge conflicts are common and are best resolved by accepting one side and re-running npm install. If both package-lock.json and npm-shrinkwrap.json exist, the shrinkwrap file takes precedence. Unlike npm-shrinkwrap.json, package-lock.json is never published to the registry.

HISTORY

Introduced in npm 5 (2017) to address long-standing reproducibility issues. lockfileVersion 2 shipped with npm 7 (backwards compatible with v1), and lockfileVersion 3 (npm 7+) dropped the legacy dependencies block for a smaller, packages-only format.

SEE ALSO

npm(1), npm-ci(1), npm-audit(1), npm-shrinkwrap(1), yarn(1)

Copied to clipboard
Kai