package-lock.json is automatically generated for any operations where npm modifies either the node_modules tree, or package.json. It describes the exact tree that was generated, such that subsequent installs are able to generate identical trees, regardless of intermediate dependency updates.

This file is intended to be committed into source repositories, and serves various purposes:

Describe a single representation of a dependency tree such that teammates, deployments, and continuous integration are guaranteed to install exactly the same dependencies.

Provide a facility for users to “time-travel” to previous states of node_modules without having to commit the directory itself.

To facilitate greater visibility of tree changes through readable source control diffs.

And optimize the installation process by allowing npm to skip repeated metadata resolutions for previously-installed packages.

One key detail about package-lock.json is that it cannot be published, and it will be ignored if found in any place other than the toplevel package. It shares a format with npm-shrinkwrap.json, which is essentially the same file, but allows publication. This is not recommended unless deploying a CLI tool or otherwise using the publication process for producing production packages.

If both package-lock.json and npm-shrinkwrap.json are present in the root of a package, package-lock.json will be completely ignored.



The name of the package this is a package-lock for. This must match what’s in package.json.


The version of the package this is a package-lock for. This must match what’s in package.json.


An integer version, starting at 1 with the version number of this document whose semantics were used when generating this package-lock.json.


This is a subresource integrity value created from the package.json. No preprocessing of the package.json should be done. Subresource integrity strings can be produced by modules like ssri.


Indicates that the install was done with the environment variable NODE_PRESERVE_SYMLINKS enabled. The installer should insist that the value of this property match that environment variable.


A mapping of package name to dependency object. Dependency objects have the following properties:


This is a specifier that uniquely identifies this package and should be usable in fetching a new copy of it.

bundled dependencies: Regardless of source, this is a version number that is purely for informational purposes.
registry sources: This is a version number. (eg, 1.2.3)
git sources: This is a git specifier with resolved committish. (eg, git+
http tarball sources: This is the URL of the tarball. (eg,
local tarball sources: This is the file URL of the tarball. (eg file:///opt/storage/example-1.3.0.tgz)
local link sources: This is the file URL of the link. (eg file:libs/our-module)

By Pankaj Kumar Agarwal

Leave a reply:

Site Footer