mirror of https://github.com/lukechilds/node.git
Browse Source
PR-URL: https://github.com/nodejs/node/pull/13276 Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: Jeremiah Senkpiel <fishrock123@rocketmail.com>v6
Kat Marchán
8 years ago
committed by
Anna Henningsen
Anna Henningsen
230 changed files with 7639 additions and 3413 deletions
File diff suppressed because it is too large
File diff suppressed because it is too large
@ -0,0 +1,145 @@ |
|||
npm-package-locks(5) -- An explanation of npm lockfiles |
|||
===================================================== |
|||
|
|||
## DESCRIPTION |
|||
|
|||
Conceptually, the "input" to npm-install(1) is a package.json(5), while its |
|||
"output" is a fully-formed `node_modules` tree: a representation of the |
|||
dependencies you declared. In an ideal world, npm would work like a pure |
|||
function: the same `package.json` should produce the exact same `node_modules` |
|||
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: |
|||
|
|||
* different versions of npm (or other package managers) may have been used to install a package, each using slightly different installation algorithms. |
|||
|
|||
* 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. |
|||
|
|||
* A dependency of one of your dependencies may have published a new version, which will update even if you used pinned dependency specifiers (`1.2.3` instead of `^1.2.3`) |
|||
|
|||
* 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. |
|||
|
|||
As an example, consider package A: |
|||
|
|||
{ |
|||
"name": "A", |
|||
"version": "0.1.0", |
|||
"dependencies": { |
|||
"B": "<0.1.0" |
|||
} |
|||
} |
|||
|
|||
package B: |
|||
|
|||
{ |
|||
"name": "B", |
|||
"version": "0.0.1", |
|||
"dependencies": { |
|||
"C": "<0.1.0" |
|||
} |
|||
} |
|||
|
|||
and package C: |
|||
|
|||
{ |
|||
"name": "C", |
|||
"version": "0.0.1" |
|||
} |
|||
|
|||
If these are the only versions of A, B, and C available in the |
|||
registry, then a normal `npm install A` will install: |
|||
|
|||
A@0.1.0 |
|||
`-- B@0.0.1 |
|||
`-- C@0.0.1 |
|||
|
|||
However, if B@0.0.2 is published, then a fresh `npm install A` will |
|||
install: |
|||
|
|||
A@0.1.0 |
|||
`-- B@0.0.2 |
|||
`-- C@0.0.1 |
|||
|
|||
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. |
|||
|
|||
To prevent this potential issue, npm uses package-lock.json(5) or, if present, |
|||
npm-shrinkwrap.json(5). These files are called package locks, or lockfiles. |
|||
|
|||
Whenever you run `npm install`, npm generates or updates your package lock, |
|||
which will look something like this: |
|||
|
|||
{ |
|||
"name": "A", |
|||
"version": "0.1.0", |
|||
...metadata fields... |
|||
"dependencies": { |
|||
"B": { |
|||
"version": "0.0.1", |
|||
"resolved": "https://registry.npmjs.org/B/-/B-0.0.1.tgz", |
|||
"integrity": "sha512-DeAdb33F+" |
|||
"dependencies": { |
|||
"C": { |
|||
"version": "git://github.com/org/C.git#5c380ae319fc4efe9e7f2d9c78b0faa588fd99b4" |
|||
} |
|||
} |
|||
} |
|||
} |
|||
} |
|||
|
|||
This file describes an *exact*, and more importantly *reproducible* |
|||
`node_modules` tree. Once it's present, and future installation will base its |
|||
work off this file, instead of recalculating dependency versions off |
|||
package.json(5). |
|||
|
|||
The presence of a package lock changes the installation behavior such that: |
|||
|
|||
1. The module tree described by the package lock is reproduced. This means |
|||
reproducing the structure described in the file, using the specific files |
|||
referenced in "resolved" if available, falling back to normal package resolution |
|||
using "version" if one isn't. |
|||
|
|||
2. The tree is walked and any missing dependencies are installed in the usual |
|||
fashion. |
|||
|
|||
If `preshrinkwrap`, `shrinkwrap` or `postshrinkwrap` are in the `scripts` |
|||
property of the `package.json`, they will be executed in order. `preshrinkwrap` |
|||
and `shrinkwrap` are executed before the shrinkwrap, `postshrinkwrap` is |
|||
executed afterwards. These scripts run for both `package-lock.json` and |
|||
`npm-shrinkwrap.json`. For example to run some postprocessing on the generated |
|||
file: |
|||
|
|||
"scripts": { |
|||
"postshrinkwrap": "json -I -e \"this.myMetadata = $MY_APP_METADATA\"" |
|||
} |
|||
|
|||
|
|||
### Using locked packages |
|||
|
|||
Using a locked package is no different than using any package without a package |
|||
lock: any commands that update `node_modules` and/or `package.json`'s |
|||
dependencies will automatically sync the existing lockfile. This includes `npm |
|||
install`, `npm rm`, `npm update`, etc. To prevent this update from happening, |
|||
you can use the `--no-save` option to prevent saving altogether, or |
|||
`--no-shrinkwrap` to allow `package.json` to be updated while leaving |
|||
`package-lock.json` or `npm-shrinkwrap.json` intact. |
|||
|
|||
It is highly recommended you commit the generated package lock to source |
|||
control: this will allow anyone else on your team, your deployments, your |
|||
CI/continuous integration, and anyone else who runs `npm install` in your |
|||
package source to get the exact same dependency tree that you were developing |
|||
on. Additionally, the diffs from these changes are human-readable and will |
|||
inform you of any changes npm has made to your `node_modules`, so you can notice |
|||
if any transitive dependencies were updated, hoisted, etc. |
|||
|
|||
## SEE ALSO |
|||
|
|||
* https://medium.com/@sdboyer/so-you-want-to-write-a-package-manager-4ae9c17d9527 |
|||
* package.json(5) |
|||
* package-lock.json(5) |
|||
* npm-shrinkwrap.json(5) |
|||
* npm-shrinkwrap(1) |
|||
@ -0,0 +1,27 @@ |
|||
npm-shrinkwrap.json(5) -- A publishable lockfile |
|||
===================================================== |
|||
|
|||
## DESCRIPTION |
|||
|
|||
`npm-shrinkwrap.json` is a file created by npm-shrinkwrap(1). It is identical to |
|||
`package-lock.json`, with one major caveat: Unlike `package-lock.json`, |
|||
`npm-shrinwkrap.json` may be included when publishing a package. |
|||
|
|||
The recommended use-case for `npm-shrinkwrap.json` is applications deployed |
|||
through the publishing process on the registry: for example, daemons and |
|||
command-line tools intended as global installs or `devDependencies`. It's |
|||
strongly discouraged for library authors to publish this file, since that would |
|||
prevent end users from having control over transitive dependency updates. |
|||
|
|||
Additionally, if both `package-lock.json` and `npm-shrinwkrap.json` are present |
|||
in a package root, `package-lock.json` will be ignored in favor of this file. |
|||
|
|||
For full details and description of the `npm-shrinkwrap.json` file format, refer |
|||
to the manual page for package-lock.json(5). |
|||
|
|||
## SEE ALSO |
|||
|
|||
* npm-shrinkwrap(1) |
|||
* package-lock.json(5) |
|||
* package.json(5) |
|||
* npm-install(1) |
|||
@ -0,0 +1,132 @@ |
|||
package-lock.json(5) -- A manifestation of the manifest |
|||
===================================================== |
|||
|
|||
## DESCRIPTION |
|||
|
|||
`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(5), 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. |
|||
|
|||
|
|||
## FILE FORMAT |
|||
|
|||
### name |
|||
|
|||
The name of the package this is a package-lock for. This must match what's in |
|||
`package.json`. |
|||
|
|||
### version |
|||
|
|||
The version of the package this is a package-lock for. This must match what's in |
|||
`package.json`. |
|||
|
|||
### lockfileVersion |
|||
|
|||
An integer version, starting at `1` with the version number of this document |
|||
whose semantics were used when generating this `package-lock.json`. |
|||
|
|||
### packageIntegrity |
|||
|
|||
This is a [subresource |
|||
integrity](https://w3c.github.io/webappsec/specs/subresourceintegrity/) value |
|||
created from the `pacakge.json`. No preprocessing of the `package.json` should |
|||
be done. Subresource integrity strings can be produced by modules like |
|||
[`ssri`](https://www.npmjs.com/package/ssri). |
|||
|
|||
### preserveSymlinks |
|||
|
|||
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. |
|||
|
|||
### dependencies |
|||
|
|||
A mapping of package name to dependency object. Dependency objects have the |
|||
following properties: |
|||
|
|||
#### version |
|||
|
|||
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+https://example.com/foo/bar#115311855adb0789a0466714ed48a1499ffea97e`) |
|||
* http tarball sources: This is the URL of the tarball. (eg, `https://example.com/example-1.3.0.tgz`) |
|||
* 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`) |
|||
|
|||
#### integrity |
|||
|
|||
This is a [Standard Subresource |
|||
Integrity](https://w3c.github.io/webappsec/specs/subresourceintegrity/) for this |
|||
resource. |
|||
|
|||
* For bundled dependencies this is not included, regardless of source. |
|||
* For registry sources, this is the `integrity` that the registry provided, or if one wasn't provided the SHA1 in `shasum`. |
|||
* For git sources this is the specific commit hash we cloned from. |
|||
* For remote tarball sources this is an integrity based on a SHA512 of |
|||
the file. |
|||
* For local tarball sources: This is an integrity field based on the SHA512 of the file. |
|||
|
|||
#### resolved |
|||
|
|||
* For bundled dependencies this is not included, regardless of source. |
|||
* For registry sources this is path of the tarball relative to the registry |
|||
URL. If the tarball URL isn't on the same server as the registry URL then |
|||
this is a complete URL. |
|||
|
|||
#### bundled |
|||
|
|||
If true, this is the bundled dependency and will be installed by the parent |
|||
module. When installing, this module will be extracted from the parent |
|||
module during the extract phase, not installed as a separate dependency. |
|||
|
|||
#### dev |
|||
|
|||
If true then this dependency is either a development dependency ONLY of the |
|||
top level module or a transitive dependency of one. This is false for |
|||
dependencies that are both a development dependency of the top level and a |
|||
transitive dependency of a non-development dependency of the top level. |
|||
|
|||
#### optional |
|||
|
|||
If true then this dependency is either an optional dependency ONLY of the |
|||
top level module or a transitive dependency of one. This is false for |
|||
dependencies that are both an optional dependency of the top level and a |
|||
transitive dependency of a non-optional dependency of the top level. |
|||
|
|||
All optional dependencies should be included even if they're uninstallable |
|||
on the current platform. |
|||
|
|||
#### dependencies |
|||
|
|||
The dependencies of this dependency, exactly as at the top level. |
|||
|
|||
## SEE ALSO |
|||
|
|||
* npm-shrinkwrap(1) |
|||
* package-lock.json(5) |
|||
* package.json(5) |
|||
* npm-install(1) |
|||
@ -0,0 +1,148 @@ |
|||
<!doctype html> |
|||
<html> |
|||
<title>npm-package-locks</title> |
|||
<meta charset="utf-8"> |
|||
<link rel="stylesheet" type="text/css" href="../../static/style.css"> |
|||
<link rel="canonical" href="https://www.npmjs.org/doc/files/npm-package-locks.html"> |
|||
<script async=true src="../../static/toc.js"></script> |
|||
|
|||
<body> |
|||
<div id="wrapper"> |
|||
|
|||
<h1><a href="../files/npm-package-locks.html">npm-package-locks</a></h1> <p>An explanation of npm lockfiles</p> |
|||
<h2 id="description">DESCRIPTION</h2> |
|||
<p>Conceptually, the "input" to <a href="../cli/npm-install.html">npm-install(1)</a> is a <a href="../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 <a href="../files/package-lock.json.html">package-lock.json(5)</a> or, if present, |
|||
n<a href="../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, |
|||
which will look something like this:</p> |
|||
<pre><code>{ |
|||
"name": "A", |
|||
"version": "0.1.0", |
|||
...metadata fields... |
|||
"dependencies": { |
|||
"B": { |
|||
"version": "0.0.1", |
|||
"resolved": "https://registry.npmjs.org/B/-/B-0.0.1.tgz", |
|||
"integrity": "sha512-DeAdb33F+" |
|||
"dependencies": { |
|||
"C": { |
|||
"version": "git://github.com/org/C.git#5c380ae319fc4efe9e7f2d9c78b0faa588fd99b4" |
|||
} |
|||
} |
|||
} |
|||
} |
|||
} |
|||
</code></pre><p>This file describes an <em>exact</em>, and more importantly <em>reproducible</em> |
|||
<code>node_modules</code> tree. Once it's present, and future installation will base its |
|||
work off this file, instead of recalculating dependency versions off |
|||
p<a href="../files/ackage.json.html">ackage.json(5)</a>.</p> |
|||
<p>The presence of a package lock changes the installation behavior such that:</p> |
|||
<ol> |
|||
<li><p>The module tree described by the package lock is reproduced. This means |
|||
reproducing the structure described in the file, using the specific files |
|||
referenced in "resolved" if available, falling back to normal package resolution |
|||
using "version" if one isn't.</p> |
|||
</li> |
|||
<li><p>The tree is walked and any missing dependencies are installed in the usual |
|||
fashion.</p> |
|||
</li> |
|||
</ol> |
|||
<p>If <code>preshrinkwrap</code>, <code>shrinkwrap</code> or <code>postshrinkwrap</code> are in the <code>scripts</code> |
|||
property of the <code>package.json</code>, they will be executed in order. <code>preshrinkwrap</code> |
|||
and <code>shrinkwrap</code> are executed before the shrinkwrap, <code>postshrinkwrap</code> is |
|||
executed afterwards. These scripts run for both <code>package-lock.json</code> and |
|||
<code>npm-shrinkwrap.json</code>. For example to run some postprocessing on the generated |
|||
file:</p> |
|||
<pre><code>"scripts": { |
|||
"postshrinkwrap": "json -I -e \"this.myMetadata = $MY_APP_METADATA\"" |
|||
} |
|||
</code></pre><h3 id="using-locked-packages">Using locked packages</h3> |
|||
<p>Using a locked package is no different than using any package without a package |
|||
lock: any commands that update <code>node_modules</code> and/or <code>package.json</code>'s |
|||
dependencies will automatically sync the existing lockfile. This includes <code>npm |
|||
install</code>, <code>npm rm</code>, <code>npm update</code>, etc. To prevent this update from happening, |
|||
you can use the <code>--no-save</code> option to prevent saving altogether, or |
|||
<code>--no-shrinkwrap</code> to allow <code>package.json</code> to be updated while leaving |
|||
<code>package-lock.json</code> or <code>npm-shrinkwrap.json</code> intact.</p> |
|||
<p>It is highly recommended you commit the generated package lock to source |
|||
control: this will allow anyone else on your team, your deployments, your |
|||
CI/continuous integration, and anyone else who runs <code>npm install</code> in your |
|||
package source to get the exact same dependency tree that you were developing |
|||
on. Additionally, the diffs from these changes are human-readable and will |
|||
inform you of any changes npm has made to your <code>node_modules</code>, so you can notice |
|||
if any transitive dependencies were updated, hoisted, etc.</p> |
|||
<h2 id="see-also">SEE ALSO</h2> |
|||
<ul> |
|||
<li><a href="https://medium.com/@sdboyer/so-you-want-to-write-a-package-manager-4ae9c17d9527">https://medium.com/@sdboyer/so-you-want-to-write-a-package-manager-4ae9c17d9527</a></li> |
|||
<li><a href="../files/package.json.html">package.json(5)</a></li> |
|||
<li><a href="../files/package-lock.json.html">package-lock.json(5)</a></li> |
|||
<li><a href="../files/npm-shrinkwrap.json.html">npm-shrinkwrap.json(5)</a></li> |
|||
<li><a href="../cli/npm-shrinkwrap.html">npm-shrinkwrap(1)</a></li> |
|||
</ul> |
|||
|
|||
</div> |
|||
|
|||
<table border=0 cellspacing=0 cellpadding=0 id=npmlogo> |
|||
<tr><td style="width:180px;height:10px;background:rgb(237,127,127)" colspan=18> </td></tr> |
|||
<tr><td rowspan=4 style="width:10px;height:10px;background:rgb(237,127,127)"> </td><td style="width:40px;height:10px;background:#fff" colspan=4> </td><td style="width:10px;height:10px;background:rgb(237,127,127)" rowspan=4> </td><td style="width:40px;height:10px;background:#fff" colspan=4> </td><td rowspan=4 style="width:10px;height:10px;background:rgb(237,127,127)"> </td><td colspan=6 style="width:60px;height:10px;background:#fff"> </td><td style="width:10px;height:10px;background:rgb(237,127,127)" rowspan=4> </td></tr> |
|||
<tr><td colspan=2 style="width:20px;height:30px;background:#fff" rowspan=3> </td><td style="width:10px;height:10px;background:rgb(237,127,127)" rowspan=3> </td><td style="width:10px;height:10px;background:#fff" rowspan=3> </td><td style="width:20px;height:10px;background:#fff" rowspan=4 colspan=2> </td><td style="width:10px;height:20px;background:rgb(237,127,127)" rowspan=2> </td><td style="width:10px;height:10px;background:#fff" rowspan=3> </td><td style="width:20px;height:10px;background:#fff" rowspan=3 colspan=2> </td><td style="width:10px;height:10px;background:rgb(237,127,127)" rowspan=3> </td><td style="width:10px;height:10px;background:#fff" rowspan=3> </td><td style="width:10px;height:10px;background:rgb(237,127,127)" rowspan=3> </td></tr> |
|||
<tr><td style="width:10px;height:10px;background:#fff" rowspan=2> </td></tr> |
|||
<tr><td style="width:10px;height:10px;background:#fff"> </td></tr> |
|||
<tr><td style="width:60px;height:10px;background:rgb(237,127,127)" colspan=6> </td><td colspan=10 style="width:10px;height:10px;background:rgb(237,127,127)"> </td></tr> |
|||
<tr><td colspan=5 style="width:50px;height:10px;background:#fff"> </td><td style="width:40px;height:10px;background:rgb(237,127,127)" colspan=4> </td><td style="width:90px;height:10px;background:#fff" colspan=9> </td></tr> |
|||
</table> |
|||
<p id="footer">npm-package-locks — npm@5.0.0</p> |
|||
@ -0,0 +1,45 @@ |
|||
<!doctype html> |
|||
<html> |
|||
<title>npm-shrinkwrap.json</title> |
|||
<meta charset="utf-8"> |
|||
<link rel="stylesheet" type="text/css" href="../../static/style.css"> |
|||
<link rel="canonical" href="https://www.npmjs.org/doc/files/npm-shrinkwrap.json.html"> |
|||
<script async=true src="../../static/toc.js"></script> |
|||
|
|||
<body> |
|||
<div id="wrapper"> |
|||
|
|||
<h1><a href="../files/npm-shrinkwrap.json.html">npm-shrinkwrap.json</a></h1> <p>A publishable lockfile</p> |
|||
<h2 id="description">DESCRIPTION</h2> |
|||
<p><code>npm-shrinkwrap.json</code> is a file created by <a href="../cli/npm-shrinkwrap.html">npm-shrinkwrap(1)</a>. It is identical to |
|||
<code>package-lock.json</code>, with one major caveat: Unlike <code>package-lock.json</code>, |
|||
<code>npm-shrinwkrap.json</code> may be included when publishing a package.</p> |
|||
<p>The recommended use-case for <code>npm-shrinkwrap.json</code> is applications deployed |
|||
through the publishing process on the registry: for example, daemons and |
|||
command-line tools intended as global installs or <code>devDependencies</code>. It's |
|||
strongly discouraged for library authors to publish this file, since that would |
|||
prevent end users from having control over transitive dependency updates.</p> |
|||
<p>Additionally, if both <code>package-lock.json</code> and <code>npm-shrinwkrap.json</code> are present |
|||
in a package root, <code>package-lock.json</code> will be ignored in favor of this file.</p> |
|||
<p>For full details and description of the <code>npm-shrinkwrap.json</code> file format, refer |
|||
to the manual page for <a href="../files/package-lock.json.html">package-lock.json(5)</a>.</p> |
|||
<h2 id="see-also">SEE ALSO</h2> |
|||
<ul> |
|||
<li><a href="../cli/npm-shrinkwrap.html">npm-shrinkwrap(1)</a></li> |
|||
<li><a href="../files/package-lock.json.html">package-lock.json(5)</a></li> |
|||
<li><a href="../files/package.json.html">package.json(5)</a></li> |
|||
<li><a href="../cli/npm-install.html">npm-install(1)</a></li> |
|||
</ul> |
|||
|
|||
</div> |
|||
|
|||
<table border=0 cellspacing=0 cellpadding=0 id=npmlogo> |
|||
<tr><td style="width:180px;height:10px;background:rgb(237,127,127)" colspan=18> </td></tr> |
|||
<tr><td rowspan=4 style="width:10px;height:10px;background:rgb(237,127,127)"> </td><td style="width:40px;height:10px;background:#fff" colspan=4> </td><td style="width:10px;height:10px;background:rgb(237,127,127)" rowspan=4> </td><td style="width:40px;height:10px;background:#fff" colspan=4> </td><td rowspan=4 style="width:10px;height:10px;background:rgb(237,127,127)"> </td><td colspan=6 style="width:60px;height:10px;background:#fff"> </td><td style="width:10px;height:10px;background:rgb(237,127,127)" rowspan=4> </td></tr> |
|||
<tr><td colspan=2 style="width:20px;height:30px;background:#fff" rowspan=3> </td><td style="width:10px;height:10px;background:rgb(237,127,127)" rowspan=3> </td><td style="width:10px;height:10px;background:#fff" rowspan=3> </td><td style="width:20px;height:10px;background:#fff" rowspan=4 colspan=2> </td><td style="width:10px;height:20px;background:rgb(237,127,127)" rowspan=2> </td><td style="width:10px;height:10px;background:#fff" rowspan=3> </td><td style="width:20px;height:10px;background:#fff" rowspan=3 colspan=2> </td><td style="width:10px;height:10px;background:rgb(237,127,127)" rowspan=3> </td><td style="width:10px;height:10px;background:#fff" rowspan=3> </td><td style="width:10px;height:10px;background:rgb(237,127,127)" rowspan=3> </td></tr> |
|||
<tr><td style="width:10px;height:10px;background:#fff" rowspan=2> </td></tr> |
|||
<tr><td style="width:10px;height:10px;background:#fff"> </td></tr> |
|||
<tr><td style="width:60px;height:10px;background:rgb(237,127,127)" colspan=6> </td><td colspan=10 style="width:10px;height:10px;background:rgb(237,127,127)"> </td></tr> |
|||
<tr><td colspan=5 style="width:50px;height:10px;background:#fff"> </td><td style="width:40px;height:10px;background:rgb(237,127,127)" colspan=4> </td><td style="width:90px;height:10px;background:#fff" colspan=9> </td></tr> |
|||
</table> |
|||
<p id="footer">npm-shrinkwrap.json — npm@5.0.0</p> |
|||
@ -0,0 +1,127 @@ |
|||
<!doctype html> |
|||
<html> |
|||
<title>package-lock.json</title> |
|||
<meta charset="utf-8"> |
|||
<link rel="stylesheet" type="text/css" href="../../static/style.css"> |
|||
<link rel="canonical" href="https://www.npmjs.org/doc/files/package-lock.json.html"> |
|||
<script async=true src="../../static/toc.js"></script> |
|||
|
|||
<body> |
|||
<div id="wrapper"> |
|||
|
|||
<h1><a href="../files/package-lock.json.html">package-lock.json</a></h1> <p>A manifestation of the manifest</p> |
|||
<h2 id="description">DESCRIPTION</h2> |
|||
<p><code>package-lock.json</code> is automatically generated for any operations where npm |
|||
modifies either the <code>node_modules</code> tree, or <code>package.json</code>. It describes the |
|||
exact tree that was generated, such that subsequent installs are able to |
|||
generate identical trees, regardless of intermediate dependency updates.</p> |
|||
<p>This file is intended to be committed into source repositories, and serves |
|||
various purposes:</p> |
|||
<ul> |
|||
<li><p>Describe a single representation of a dependency tree such that teammates, deployments, and continuous integration are guaranteed to install exactly the same dependencies.</p> |
|||
</li> |
|||
<li><p>Provide a facility for users to "time-travel" to previous states of <code>node_modules</code> without having to commit the directory itself.</p> |
|||
</li> |
|||
<li><p>To facilitate greater visibility of tree changes through readable source control diffs.</p> |
|||
</li> |
|||
<li><p>And optimize the installation process by allowing npm to skip repeated metadata resolutions for previously-installed packages.</p> |
|||
</li> |
|||
</ul> |
|||
<p>One key detail about <code>package-lock.json</code> 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 <a href="../files/npm-shrinkwrap.json.html">npm-shrinkwrap.json(5)</a>, 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.</p> |
|||
<p>If both <code>package-lock.json</code> and <code>npm-shrinkwrap.json</code> are present in the root of |
|||
a package, <code>package-lock.json</code> will be completely ignored.</p> |
|||
<h2 id="file-format">FILE FORMAT</h2> |
|||
<h3 id="name">name</h3> |
|||
<p>The name of the package this is a package-lock for. This must match what's in |
|||
<code>package.json</code>.</p> |
|||
<h3 id="version">version</h3> |
|||
<p>The version of the package this is a package-lock for. This must match what's in |
|||
<code>package.json</code>.</p> |
|||
<h3 id="lockfileversion">lockfileVersion</h3> |
|||
<p>An integer version, starting at <code>1</code> with the version number of this document |
|||
whose semantics were used when generating this <code>package-lock.json</code>.</p> |
|||
<h3 id="packageintegrity">packageIntegrity</h3> |
|||
<p>This is a <a href="https://w3c.github.io/webappsec/specs/subresourceintegrity/">subresource |
|||
integrity</a> value |
|||
created from the <code>pacakge.json</code>. No preprocessing of the <code>package.json</code> should |
|||
be done. Subresource integrity strings can be produced by modules like |
|||
<a href="https://www.npmjs.com/package/ssri"><code>ssri</code></a>.</p> |
|||
<h3 id="preservesymlinks">preserveSymlinks</h3> |
|||
<p>Indicates that the install was done with the environment variable |
|||
<code>NODE_PRESERVE_SYMLINKS</code> enabled. The installer should insist that the value of |
|||
this property match that environment variable.</p> |
|||
<h3 id="dependencies">dependencies</h3> |
|||
<p>A mapping of package name to dependency object. Dependency objects have the |
|||
following properties:</p> |
|||
<h4 id="version">version</h4> |
|||
<p>This is a specifier that uniquely identifies this package and should be |
|||
usable in fetching a new copy of it.</p> |
|||
<ul> |
|||
<li>bundled dependencies: Regardless of source, this is a version number that is purely for informational purposes.</li> |
|||
<li>registry sources: This is a version number. (eg, <code>1.2.3</code>)</li> |
|||
<li>git sources: This is a git specifier with resolved committish. (eg, <code>git+https://example.com/foo/bar#115311855adb0789a0466714ed48a1499ffea97e</code>)</li> |
|||
<li>http tarball sources: This is the URL of the tarball. (eg, <code>https://example.com/example-1.3.0.tgz</code>)</li> |
|||
<li>local tarball sources: This is the file URL of the tarball. (eg <code>file:///opt/storage/example-1.3.0.tgz</code>)</li> |
|||
<li>local link sources: This is the file URL of the link. (eg <code>file:libs/our-module</code>)</li> |
|||
</ul> |
|||
<h4 id="integrity">integrity</h4> |
|||
<p>This is a <a href="https://w3c.github.io/webappsec/specs/subresourceintegrity/">Standard Subresource |
|||
Integrity</a> for this |
|||
resource.</p> |
|||
<ul> |
|||
<li>For bundled dependencies this is not included, regardless of source.</li> |
|||
<li>For registry sources, this is the <code>integrity</code> that the registry provided, or if one wasn't provided the SHA1 in <code>shasum</code>.</li> |
|||
<li>For git sources this is the specific commit hash we cloned from.</li> |
|||
<li>For remote tarball sources this is an integrity based on a SHA512 of |
|||
the file.</li> |
|||
<li>For local tarball sources: This is an integrity field based on the SHA512 of the file.</li> |
|||
</ul> |
|||
<h4 id="resolved">resolved</h4> |
|||
<ul> |
|||
<li>For bundled dependencies this is not included, regardless of source.</li> |
|||
<li>For registry sources this is path of the tarball relative to the registry |
|||
URL. If the tarball URL isn't on the same server as the registry URL then |
|||
this is a complete URL.</li> |
|||
</ul> |
|||
<h4 id="bundled">bundled</h4> |
|||
<p>If true, this is the bundled dependency and will be installed by the parent |
|||
module. When installing, this module will be extracted from the parent |
|||
module during the extract phase, not installed as a separate dependency.</p> |
|||
<h4 id="dev">dev</h4> |
|||
<p>If true then this dependency is either a development dependency ONLY of the |
|||
top level module or a transitive dependency of one. This is false for |
|||
dependencies that are both a development dependency of the top level and a |
|||
transitive dependency of a non-development dependency of the top level.</p> |
|||
<h4 id="optional">optional</h4> |
|||
<p>If true then this dependency is either an optional dependency ONLY of the |
|||
top level module or a transitive dependency of one. This is false for |
|||
dependencies that are both an optional dependency of the top level and a |
|||
transitive dependency of a non-optional dependency of the top level.</p> |
|||
<p>All optional dependencies should be included even if they're uninstallable |
|||
on the current platform.</p> |
|||
<h4 id="dependencies">dependencies</h4> |
|||
<p>The dependencies of this dependency, exactly as at the top level.</p> |
|||
<h2 id="see-also">SEE ALSO</h2> |
|||
<ul> |
|||
<li><a href="../cli/npm-shrinkwrap.html">npm-shrinkwrap(1)</a></li> |
|||
<li><a href="../files/package-lock.json.html">package-lock.json(5)</a></li> |
|||
<li><a href="../files/package.json.html">package.json(5)</a></li> |
|||
<li><a href="../cli/npm-install.html">npm-install(1)</a></li> |
|||
</ul> |
|||
|
|||
</div> |
|||
|
|||
<table border=0 cellspacing=0 cellpadding=0 id=npmlogo> |
|||
<tr><td style="width:180px;height:10px;background:rgb(237,127,127)" colspan=18> </td></tr> |
|||
<tr><td rowspan=4 style="width:10px;height:10px;background:rgb(237,127,127)"> </td><td style="width:40px;height:10px;background:#fff" colspan=4> </td><td style="width:10px;height:10px;background:rgb(237,127,127)" rowspan=4> </td><td style="width:40px;height:10px;background:#fff" colspan=4> </td><td rowspan=4 style="width:10px;height:10px;background:rgb(237,127,127)"> </td><td colspan=6 style="width:60px;height:10px;background:#fff"> </td><td style="width:10px;height:10px;background:rgb(237,127,127)" rowspan=4> </td></tr> |
|||
<tr><td colspan=2 style="width:20px;height:30px;background:#fff" rowspan=3> </td><td style="width:10px;height:10px;background:rgb(237,127,127)" rowspan=3> </td><td style="width:10px;height:10px;background:#fff" rowspan=3> </td><td style="width:20px;height:10px;background:#fff" rowspan=4 colspan=2> </td><td style="width:10px;height:20px;background:rgb(237,127,127)" rowspan=2> </td><td style="width:10px;height:10px;background:#fff" rowspan=3> </td><td style="width:20px;height:10px;background:#fff" rowspan=3 colspan=2> </td><td style="width:10px;height:10px;background:rgb(237,127,127)" rowspan=3> </td><td style="width:10px;height:10px;background:#fff" rowspan=3> </td><td style="width:10px;height:10px;background:rgb(237,127,127)" rowspan=3> </td></tr> |
|||
<tr><td style="width:10px;height:10px;background:#fff" rowspan=2> </td></tr> |
|||
<tr><td style="width:10px;height:10px;background:#fff"> </td></tr> |
|||
<tr><td style="width:60px;height:10px;background:rgb(237,127,127)" colspan=6> </td><td colspan=10 style="width:10px;height:10px;background:rgb(237,127,127)"> </td></tr> |
|||
<tr><td colspan=5 style="width:50px;height:10px;background:#fff"> </td><td style="width:40px;height:10px;background:rgb(237,127,127)" colspan=4> </td><td style="width:90px;height:10px;background:#fff" colspan=9> </td></tr> |
|||
</table> |
|||
<p id="footer">package-lock.json — npm@5.0.0</p> |
|||
@ -1,9 +1,8 @@ |
|||
'use strict' |
|||
var lifecycle = require('../../utils/lifecycle.js') |
|||
var packageId = require('../../utils/package-id.js') |
|||
var moduleStagingPath = require('../module-staging-path.js') |
|||
|
|||
module.exports = function (staging, pkg, log, next) { |
|||
log.silly('preinstall', packageId(pkg)) |
|||
lifecycle(pkg.package, 'preinstall', moduleStagingPath(staging, pkg), false, false, next) |
|||
lifecycle(pkg.package, 'preinstall', pkg.path, false, false, next) |
|||
} |
|||
|
|||
Some files were not shown because too many files changed in this diff
Loading…
Reference in new issue