<h1><ahref="../files/npm-package-locks.html">npm-package-locks</a></h1><p>An explanation of npm lockfiles</p>
<h2id="description">DESCRIPTION</h2>
<p>Conceptually, the "input" to <ahref="../cli/npm-install.html">npm-install(1)</a> is a <ahref="../files/package.json.html">package.json(5)</a>, while its
"output" is a fully-formed <code>node_modules</code> tree: a representation of the
dependencies you declared. In an ideal world, npm would work like a pure
function: the same <code>package.json</code> should produce the exact same <code>node_modules</code>
tree, any time. In some cases, this is indeed true. But in many others, npm is
unable to do this. There are multiple reasons for this:</p>
<ul>
<li><p>different versions of npm (or other package managers) may have been used to install a package, each using slightly different installation algorithms.</p>
</li>
<li><p>a new version of a direct semver-range package may have been published since the last time your packages were installed, and thus a newer version will be used.</p>
</li>
<li><p>A dependency of one of your dependencies may have published a new version, which will update even if you used pinned dependency specifiers (<code>1.2.3</code> instead of <code>^1.2.3</code>)</p>
</li>
<li><p>The registry you installed from is no longer available, or allows mutation of versions (unlike the primary npm registry), and a different version of a package exists under the same version number now.</p>
</li>
</ul>
<p>As an example, consider package A:</p>
<pre><code>{
"name": "A",
"version": "0.1.0",
"dependencies": {
"B": "<0.1.0"
}
}
</code></pre><p>package B:</p>
<pre><code>{
"name": "B",
"version": "0.0.1",
"dependencies": {
"C": "<0.1.0"
}
}
</code></pre><p>and package C:</p>
<pre><code>{
"name": "C",
"version": "0.0.1"
}
</code></pre><p>If these are the only versions of A, B, and C available in the
registry, then a normal <code>npm install A</code> will install:</p>
<pre><code>A@0.1.0
`-- B@0.0.1
`-- C@0.0.1
</code></pre><p>However, if B@0.0.2 is published, then a fresh <code>npm install A</code> will
install:</p>
<pre><code>A@0.1.0
`-- B@0.0.2
`-- C@0.0.1
</code></pre><p>assuming the new version did not modify B's dependencies. Of course,
the new version of B could include a new version of C and any number
of new dependencies. If such changes are undesirable, the author of A
could specify a dependency on B@0.0.1. However, if A's author and B's
author are not the same person, there's no way for A's author to say
that he or she does not want to pull in newly published versions of C
when B hasn't changed at all.</p>
<p>To prevent this potential issue, npm uses <ahref="../files/package-lock.json.html">package-lock.json(5)</a> or, if present,
n<ahref="../files/pm-shrinkwrap.json.html">pm-shrinkwrap.json(5)</a>. These files are called package locks, or lockfiles.</p>
<p>Whenever you run <code>npm install</code>, npm generates or updates your package lock,
