diff options
Diffstat (limited to 'deps/node/deps/npm/html/doc/files')
| -rw-r--r-- | deps/node/deps/npm/html/doc/files/npm-folders.html | 183 | ||||
| -rw-r--r-- | deps/node/deps/npm/html/doc/files/npm-global.html | 183 | ||||
| -rw-r--r-- | deps/node/deps/npm/html/doc/files/npm-json.html | 578 | ||||
| -rw-r--r-- | deps/node/deps/npm/html/doc/files/npm-package-locks.html | 157 | ||||
| -rw-r--r-- | deps/node/deps/npm/html/doc/files/npm-shrinkwrap.json.html | 45 | ||||
| -rw-r--r-- | deps/node/deps/npm/html/doc/files/npmrc.html | 86 | ||||
| -rw-r--r-- | deps/node/deps/npm/html/doc/files/package-lock.json.html | 133 | ||||
| -rw-r--r-- | deps/node/deps/npm/html/doc/files/package.json.html | 578 |
8 files changed, 0 insertions, 1943 deletions
diff --git a/deps/node/deps/npm/html/doc/files/npm-folders.html b/deps/node/deps/npm/html/doc/files/npm-folders.html deleted file mode 100644 index 5ad8e306..00000000 --- a/deps/node/deps/npm/html/doc/files/npm-folders.html +++ /dev/null @@ -1,183 +0,0 @@ -<!doctype html> -<html> - <title>npm-folders</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-folders.html"> - <script async=true src="../../static/toc.js"></script> - - <body> - <div id="wrapper"> - -<h1><a href="../files/npm-folders.html">npm-folders</a></h1> <p>Folder Structures Used by npm</p> -<h2 id="description">DESCRIPTION</h2> -<p>npm puts various things on your computer. That's its job.</p> -<p>This document will tell you what it puts where.</p> -<h3 id="tldr">tl;dr</h3> -<ul> -<li>Local install (default): puts stuff in <code>./node_modules</code> of the current -package root.</li> -<li>Global install (with <code>-g</code>): puts stuff in /usr/local or wherever node -is installed.</li> -<li>Install it <strong>locally</strong> if you're going to <code>require()</code> it.</li> -<li>Install it <strong>globally</strong> if you're going to run it on the command line.</li> -<li>If you need both, then install it in both places, or use <code>npm link</code>.</li> -</ul> -<h3 id="prefix-configuration">prefix Configuration</h3> -<p>The <code>prefix</code> config defaults to the location where node is installed. -On most systems, this is <code>/usr/local</code>. On Windows, it's <code>%AppData%\npm</code>. -On Unix systems, it's one level up, since node is typically installed at -<code>{prefix}/bin/node</code> rather than <code>{prefix}/node.exe</code>.</p> -<p>When the <code>global</code> flag is set, npm installs things into this prefix. -When it is not set, it uses the root of the current package, or the -current working directory if not in a package already.</p> -<h3 id="node-modules">Node Modules</h3> -<p>Packages are dropped into the <code>node_modules</code> folder under the <code>prefix</code>. -When installing locally, this means that you can -<code>require("packagename")</code> to load its main module, or -<code>require("packagename/lib/path/to/sub/module")</code> to load other modules.</p> -<p>Global installs on Unix systems go to <code>{prefix}/lib/node_modules</code>. -Global installs on Windows go to <code>{prefix}/node_modules</code> (that is, no -<code>lib</code> folder.)</p> -<p>Scoped packages are installed the same way, except they are grouped together -in a sub-folder of the relevant <code>node_modules</code> folder with the name of that -scope prefix by the @ symbol, e.g. <code>npm install @myorg/package</code> would place -the package in <code>{prefix}/node_modules/@myorg/package</code>. See <code><a href="../misc/scope.html">scope(7)</a></code> for -more details.</p> -<p>If you wish to <code>require()</code> a package, then install it locally.</p> -<h3 id="executables">Executables</h3> -<p>When in global mode, executables are linked into <code>{prefix}/bin</code> on Unix, -or directly into <code>{prefix}</code> on Windows.</p> -<p>When in local mode, executables are linked into -<code>./node_modules/.bin</code> so that they can be made available to scripts run -through npm. (For example, so that a test runner will be in the path -when you run <code>npm test</code>.)</p> -<h3 id="man-pages">Man Pages</h3> -<p>When in global mode, man pages are linked into <code>{prefix}/share/man</code>.</p> -<p>When in local mode, man pages are not installed.</p> -<p>Man pages are not installed on Windows systems.</p> -<h3 id="cache">Cache</h3> -<p>See <code><a href="../cli/npm-cache.html">npm-cache(1)</a></code>. Cache files are stored in <code>~/.npm</code> on Posix, or -<code>%AppData%/npm-cache</code> on Windows.</p> -<p>This is controlled by the <code>cache</code> configuration param.</p> -<h3 id="temp-files">Temp Files</h3> -<p>Temporary files are stored by default in the folder specified by the -<code>tmp</code> config, which defaults to the TMPDIR, TMP, or TEMP environment -variables, or <code>/tmp</code> on Unix and <code>c:\windows\temp</code> on Windows.</p> -<p>Temp files are given a unique folder under this root for each run of the -program, and are deleted upon successful exit.</p> -<h2 id="more-information">More Information</h2> -<p>When installing locally, npm first tries to find an appropriate -<code>prefix</code> folder. This is so that <code>npm install foo@1.2.3</code> will install -to the sensible root of your package, even if you happen to have <code>cd</code>ed -into some other folder.</p> -<p>Starting at the $PWD, npm will walk up the folder tree checking for a -folder that contains either a <code>package.json</code> file, or a <code>node_modules</code> -folder. If such a thing is found, then that is treated as the effective -"current directory" for the purpose of running npm commands. (This -behavior is inspired by and similar to git's .git-folder seeking -logic when running git commands in a working dir.)</p> -<p>If no package root is found, then the current folder is used.</p> -<p>When you run <code>npm install foo@1.2.3</code>, then the package is loaded into -the cache, and then unpacked into <code>./node_modules/foo</code>. Then, any of -foo's dependencies are similarly unpacked into -<code>./node_modules/foo/node_modules/...</code>.</p> -<p>Any bin files are symlinked to <code>./node_modules/.bin/</code>, so that they may -be found by npm scripts when necessary.</p> -<h3 id="global-installation">Global Installation</h3> -<p>If the <code>global</code> configuration is set to true, then npm will -install packages "globally".</p> -<p>For global installation, packages are installed roughly the same way, -but using the folders described above.</p> -<h3 id="cycles-conflicts-and-folder-parsimony">Cycles, Conflicts, and Folder Parsimony</h3> -<p>Cycles are handled using the property of node's module system that it -walks up the directories looking for <code>node_modules</code> folders. So, at every -stage, if a package is already installed in an ancestor <code>node_modules</code> -folder, then it is not installed at the current location.</p> -<p>Consider the case above, where <code>foo -> bar -> baz</code>. Imagine if, in -addition to that, baz depended on bar, so you'd have: -<code>foo -> bar -> baz -> bar -> baz ...</code>. However, since the folder -structure is: <code>foo/node_modules/bar/node_modules/baz</code>, there's no need to -put another copy of bar into <code>.../baz/node_modules</code>, since when it calls -require("bar"), it will get the copy that is installed in -<code>foo/node_modules/bar</code>.</p> -<p>This shortcut is only used if the exact same -version would be installed in multiple nested <code>node_modules</code> folders. It -is still possible to have <code>a/node_modules/b/node_modules/a</code> if the two -"a" packages are different versions. However, without repeating the -exact same package multiple times, an infinite regress will always be -prevented.</p> -<p>Another optimization can be made by installing dependencies at the -highest level possible, below the localized "target" folder.</p> -<h4 id="example">Example</h4> -<p>Consider this dependency graph:</p> -<pre><code>foo -+-- blerg@1.2.5 -+-- bar@1.2.3 -| +-- blerg@1.x (latest=1.3.7) -| +-- baz@2.x -| | `-- quux@3.x -| | `-- bar@1.2.3 (cycle) -| `-- asdf@* -`-- baz@1.2.3 - `-- quux@3.x - `-- bar</code></pre><p>In this case, we might expect a folder structure like this:</p> -<pre><code>foo -+-- node_modules - +-- blerg (1.2.5) <---[A] - +-- bar (1.2.3) <---[B] - | `-- node_modules - | +-- baz (2.0.2) <---[C] - | | `-- node_modules - | | `-- quux (3.2.0) - | `-- asdf (2.3.4) - `-- baz (1.2.3) <---[D] - `-- node_modules - `-- quux (3.2.0) <---[E]</code></pre><p>Since foo depends directly on <code>bar@1.2.3</code> and <code>baz@1.2.3</code>, those are -installed in foo's <code>node_modules</code> folder.</p> -<p>Even though the latest copy of blerg is 1.3.7, foo has a specific -dependency on version 1.2.5. So, that gets installed at [A]. Since the -parent installation of blerg satisfies bar's dependency on <code>blerg@1.x</code>, -it does not install another copy under [B].</p> -<p>Bar [B] also has dependencies on baz and asdf, so those are installed in -bar's <code>node_modules</code> folder. Because it depends on <code>baz@2.x</code>, it cannot -re-use the <code>baz@1.2.3</code> installed in the parent <code>node_modules</code> folder [D], -and must install its own copy [C].</p> -<p>Underneath bar, the <code>baz -> quux -> bar</code> dependency creates a cycle. -However, because bar is already in quux's ancestry [B], it does not -unpack another copy of bar into that folder.</p> -<p>Underneath <code>foo -> baz</code> [D], quux's [E] folder tree is empty, because its -dependency on bar is satisfied by the parent folder copy installed at [B].</p> -<p>For a graphical breakdown of what is installed where, use <code>npm ls</code>.</p> -<h3 id="publishing">Publishing</h3> -<p>Upon publishing, npm will look in the <code>node_modules</code> folder. If any of -the items there are not in the <code>bundledDependencies</code> array, then they will -not be included in the package tarball.</p> -<p>This allows a package maintainer to install all of their dependencies -(and dev dependencies) locally, but only re-publish those items that -cannot be found elsewhere. See <code><a href="../files/package.json.html">package.json(5)</a></code> for more information.</p> -<h2 id="see-also">SEE ALSO</h2> -<ul> -<li><a href="../files/package.json.html">package.json(5)</a></li> -<li><a href="../cli/npm-install.html">npm-install(1)</a></li> -<li><a href="../cli/npm-pack.html">npm-pack(1)</a></li> -<li><a href="../cli/npm-cache.html">npm-cache(1)</a></li> -<li><a href="../cli/npm-config.html">npm-config(1)</a></li> -<li><a href="../files/npmrc.html">npmrc(5)</a></li> -<li><a href="../misc/npm-config.html">npm-config(7)</a></li> -<li><a href="../cli/npm-publish.html">npm-publish(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-folders — npm@6.7.0</p> - diff --git a/deps/node/deps/npm/html/doc/files/npm-global.html b/deps/node/deps/npm/html/doc/files/npm-global.html deleted file mode 100644 index 5ad8e306..00000000 --- a/deps/node/deps/npm/html/doc/files/npm-global.html +++ /dev/null @@ -1,183 +0,0 @@ -<!doctype html> -<html> - <title>npm-folders</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-folders.html"> - <script async=true src="../../static/toc.js"></script> - - <body> - <div id="wrapper"> - -<h1><a href="../files/npm-folders.html">npm-folders</a></h1> <p>Folder Structures Used by npm</p> -<h2 id="description">DESCRIPTION</h2> -<p>npm puts various things on your computer. That's its job.</p> -<p>This document will tell you what it puts where.</p> -<h3 id="tldr">tl;dr</h3> -<ul> -<li>Local install (default): puts stuff in <code>./node_modules</code> of the current -package root.</li> -<li>Global install (with <code>-g</code>): puts stuff in /usr/local or wherever node -is installed.</li> -<li>Install it <strong>locally</strong> if you're going to <code>require()</code> it.</li> -<li>Install it <strong>globally</strong> if you're going to run it on the command line.</li> -<li>If you need both, then install it in both places, or use <code>npm link</code>.</li> -</ul> -<h3 id="prefix-configuration">prefix Configuration</h3> -<p>The <code>prefix</code> config defaults to the location where node is installed. -On most systems, this is <code>/usr/local</code>. On Windows, it's <code>%AppData%\npm</code>. -On Unix systems, it's one level up, since node is typically installed at -<code>{prefix}/bin/node</code> rather than <code>{prefix}/node.exe</code>.</p> -<p>When the <code>global</code> flag is set, npm installs things into this prefix. -When it is not set, it uses the root of the current package, or the -current working directory if not in a package already.</p> -<h3 id="node-modules">Node Modules</h3> -<p>Packages are dropped into the <code>node_modules</code> folder under the <code>prefix</code>. -When installing locally, this means that you can -<code>require("packagename")</code> to load its main module, or -<code>require("packagename/lib/path/to/sub/module")</code> to load other modules.</p> -<p>Global installs on Unix systems go to <code>{prefix}/lib/node_modules</code>. -Global installs on Windows go to <code>{prefix}/node_modules</code> (that is, no -<code>lib</code> folder.)</p> -<p>Scoped packages are installed the same way, except they are grouped together -in a sub-folder of the relevant <code>node_modules</code> folder with the name of that -scope prefix by the @ symbol, e.g. <code>npm install @myorg/package</code> would place -the package in <code>{prefix}/node_modules/@myorg/package</code>. See <code><a href="../misc/scope.html">scope(7)</a></code> for -more details.</p> -<p>If you wish to <code>require()</code> a package, then install it locally.</p> -<h3 id="executables">Executables</h3> -<p>When in global mode, executables are linked into <code>{prefix}/bin</code> on Unix, -or directly into <code>{prefix}</code> on Windows.</p> -<p>When in local mode, executables are linked into -<code>./node_modules/.bin</code> so that they can be made available to scripts run -through npm. (For example, so that a test runner will be in the path -when you run <code>npm test</code>.)</p> -<h3 id="man-pages">Man Pages</h3> -<p>When in global mode, man pages are linked into <code>{prefix}/share/man</code>.</p> -<p>When in local mode, man pages are not installed.</p> -<p>Man pages are not installed on Windows systems.</p> -<h3 id="cache">Cache</h3> -<p>See <code><a href="../cli/npm-cache.html">npm-cache(1)</a></code>. Cache files are stored in <code>~/.npm</code> on Posix, or -<code>%AppData%/npm-cache</code> on Windows.</p> -<p>This is controlled by the <code>cache</code> configuration param.</p> -<h3 id="temp-files">Temp Files</h3> -<p>Temporary files are stored by default in the folder specified by the -<code>tmp</code> config, which defaults to the TMPDIR, TMP, or TEMP environment -variables, or <code>/tmp</code> on Unix and <code>c:\windows\temp</code> on Windows.</p> -<p>Temp files are given a unique folder under this root for each run of the -program, and are deleted upon successful exit.</p> -<h2 id="more-information">More Information</h2> -<p>When installing locally, npm first tries to find an appropriate -<code>prefix</code> folder. This is so that <code>npm install foo@1.2.3</code> will install -to the sensible root of your package, even if you happen to have <code>cd</code>ed -into some other folder.</p> -<p>Starting at the $PWD, npm will walk up the folder tree checking for a -folder that contains either a <code>package.json</code> file, or a <code>node_modules</code> -folder. If such a thing is found, then that is treated as the effective -"current directory" for the purpose of running npm commands. (This -behavior is inspired by and similar to git's .git-folder seeking -logic when running git commands in a working dir.)</p> -<p>If no package root is found, then the current folder is used.</p> -<p>When you run <code>npm install foo@1.2.3</code>, then the package is loaded into -the cache, and then unpacked into <code>./node_modules/foo</code>. Then, any of -foo's dependencies are similarly unpacked into -<code>./node_modules/foo/node_modules/...</code>.</p> -<p>Any bin files are symlinked to <code>./node_modules/.bin/</code>, so that they may -be found by npm scripts when necessary.</p> -<h3 id="global-installation">Global Installation</h3> -<p>If the <code>global</code> configuration is set to true, then npm will -install packages "globally".</p> -<p>For global installation, packages are installed roughly the same way, -but using the folders described above.</p> -<h3 id="cycles-conflicts-and-folder-parsimony">Cycles, Conflicts, and Folder Parsimony</h3> -<p>Cycles are handled using the property of node's module system that it -walks up the directories looking for <code>node_modules</code> folders. So, at every -stage, if a package is already installed in an ancestor <code>node_modules</code> -folder, then it is not installed at the current location.</p> -<p>Consider the case above, where <code>foo -> bar -> baz</code>. Imagine if, in -addition to that, baz depended on bar, so you'd have: -<code>foo -> bar -> baz -> bar -> baz ...</code>. However, since the folder -structure is: <code>foo/node_modules/bar/node_modules/baz</code>, there's no need to -put another copy of bar into <code>.../baz/node_modules</code>, since when it calls -require("bar"), it will get the copy that is installed in -<code>foo/node_modules/bar</code>.</p> -<p>This shortcut is only used if the exact same -version would be installed in multiple nested <code>node_modules</code> folders. It -is still possible to have <code>a/node_modules/b/node_modules/a</code> if the two -"a" packages are different versions. However, without repeating the -exact same package multiple times, an infinite regress will always be -prevented.</p> -<p>Another optimization can be made by installing dependencies at the -highest level possible, below the localized "target" folder.</p> -<h4 id="example">Example</h4> -<p>Consider this dependency graph:</p> -<pre><code>foo -+-- blerg@1.2.5 -+-- bar@1.2.3 -| +-- blerg@1.x (latest=1.3.7) -| +-- baz@2.x -| | `-- quux@3.x -| | `-- bar@1.2.3 (cycle) -| `-- asdf@* -`-- baz@1.2.3 - `-- quux@3.x - `-- bar</code></pre><p>In this case, we might expect a folder structure like this:</p> -<pre><code>foo -+-- node_modules - +-- blerg (1.2.5) <---[A] - +-- bar (1.2.3) <---[B] - | `-- node_modules - | +-- baz (2.0.2) <---[C] - | | `-- node_modules - | | `-- quux (3.2.0) - | `-- asdf (2.3.4) - `-- baz (1.2.3) <---[D] - `-- node_modules - `-- quux (3.2.0) <---[E]</code></pre><p>Since foo depends directly on <code>bar@1.2.3</code> and <code>baz@1.2.3</code>, those are -installed in foo's <code>node_modules</code> folder.</p> -<p>Even though the latest copy of blerg is 1.3.7, foo has a specific -dependency on version 1.2.5. So, that gets installed at [A]. Since the -parent installation of blerg satisfies bar's dependency on <code>blerg@1.x</code>, -it does not install another copy under [B].</p> -<p>Bar [B] also has dependencies on baz and asdf, so those are installed in -bar's <code>node_modules</code> folder. Because it depends on <code>baz@2.x</code>, it cannot -re-use the <code>baz@1.2.3</code> installed in the parent <code>node_modules</code> folder [D], -and must install its own copy [C].</p> -<p>Underneath bar, the <code>baz -> quux -> bar</code> dependency creates a cycle. -However, because bar is already in quux's ancestry [B], it does not -unpack another copy of bar into that folder.</p> -<p>Underneath <code>foo -> baz</code> [D], quux's [E] folder tree is empty, because its -dependency on bar is satisfied by the parent folder copy installed at [B].</p> -<p>For a graphical breakdown of what is installed where, use <code>npm ls</code>.</p> -<h3 id="publishing">Publishing</h3> -<p>Upon publishing, npm will look in the <code>node_modules</code> folder. If any of -the items there are not in the <code>bundledDependencies</code> array, then they will -not be included in the package tarball.</p> -<p>This allows a package maintainer to install all of their dependencies -(and dev dependencies) locally, but only re-publish those items that -cannot be found elsewhere. See <code><a href="../files/package.json.html">package.json(5)</a></code> for more information.</p> -<h2 id="see-also">SEE ALSO</h2> -<ul> -<li><a href="../files/package.json.html">package.json(5)</a></li> -<li><a href="../cli/npm-install.html">npm-install(1)</a></li> -<li><a href="../cli/npm-pack.html">npm-pack(1)</a></li> -<li><a href="../cli/npm-cache.html">npm-cache(1)</a></li> -<li><a href="../cli/npm-config.html">npm-config(1)</a></li> -<li><a href="../files/npmrc.html">npmrc(5)</a></li> -<li><a href="../misc/npm-config.html">npm-config(7)</a></li> -<li><a href="../cli/npm-publish.html">npm-publish(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-folders — npm@6.7.0</p> - diff --git a/deps/node/deps/npm/html/doc/files/npm-json.html b/deps/node/deps/npm/html/doc/files/npm-json.html deleted file mode 100644 index 751bbebd..00000000 --- a/deps/node/deps/npm/html/doc/files/npm-json.html +++ /dev/null @@ -1,578 +0,0 @@ -<!doctype html> -<html> - <title>package.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.json.html"> - <script async=true src="../../static/toc.js"></script> - - <body> - <div id="wrapper"> - -<h1><a href="../files/package.json.html">package.json</a></h1> <p>Specifics of npm's package.json handling</p> -<h2 id="description">DESCRIPTION</h2> -<p>This document is all you need to know about what's required in your package.json -file. It must be actual JSON, not just a JavaScript object literal.</p> -<p>A lot of the behavior described in this document is affected by the config -settings described in <code><a href="../misc/npm-config.html">npm-config(7)</a></code>.</p> -<h2 id="name">name</h2> -<p>If you plan to publish your package, the <em>most</em> important things in your -package.json are the name and version fields as they will be required. The name -and version together form an identifier that is assumed to be completely unique. -Changes to the package should come along with changes to the version. If you don't -plan to publish your package, the name and version fields are optional.</p> -<p>The name is what your thing is called.</p> -<p>Some rules:</p> -<ul> -<li>The name must be less than or equal to 214 characters. This includes the scope for -scoped packages.</li> -<li>The name can't start with a dot or an underscore.</li> -<li>New packages must not have uppercase letters in the name.</li> -<li>The name ends up being part of a URL, an argument on the command line, and a -folder name. Therefore, the name can't contain any non-URL-safe characters.</li> -</ul> -<p>Some tips:</p> -<ul> -<li>Don't use the same name as a core Node module.</li> -<li>Don't put "js" or "node" in the name. It's assumed that it's js, since you're -writing a package.json file, and you can specify the engine using the "engines" -field. (See below.)</li> -<li>The name will probably be passed as an argument to require(), so it should -be something short, but also reasonably descriptive.</li> -<li>You may want to check the npm registry to see if there's something by that name -already, before you get too attached to it. <a href="https://www.npmjs.com/">https://www.npmjs.com/</a></li> -</ul> -<p>A name can be optionally prefixed by a scope, e.g. <code>@myorg/mypackage</code>. See -<code><a href="../misc/npm-scope.html">npm-scope(7)</a></code> for more detail.</p> -<h2 id="version">version</h2> -<p>If you plan to publish your package, the <em>most</em> important things in your -package.json are the name and version fields as they will be required. The name -and version together form an identifier that is assumed to be completely unique. -Changes to the package should come along with changes to the version. If you don't -plan to publish your package, the name and version fields are optional.</p> -<p>Version must be parseable by -<a href="https://github.com/isaacs/node-semver">node-semver</a>, which is bundled -with npm as a dependency. (<code>npm install semver</code> to use it yourself.)</p> -<p>More on version numbers and ranges at <a href="../misc/semver.html">semver(7)</a>.</p> -<h2 id="description-1">description</h2> -<p>Put a description in it. It's a string. This helps people discover your -package, as it's listed in <code>npm search</code>.</p> -<h2 id="keywords">keywords</h2> -<p>Put keywords in it. It's an array of strings. This helps people -discover your package as it's listed in <code>npm search</code>.</p> -<h2 id="homepage">homepage</h2> -<p>The url to the project homepage.</p> -<p>Example:</p> -<pre><code>"homepage": "https://github.com/owner/project#readme"</code></pre><h2 id="bugs">bugs</h2> -<p>The url to your project's issue tracker and / or the email address to which -issues should be reported. These are helpful for people who encounter issues -with your package.</p> -<p>It should look like this:</p> -<pre><code>{ "url" : "https://github.com/owner/project/issues" -, "email" : "project@hostname.com" -}</code></pre><p>You can specify either one or both values. If you want to provide only a url, -you can specify the value for "bugs" as a simple string instead of an object.</p> -<p>If a url is provided, it will be used by the <code>npm bugs</code> command.</p> -<h2 id="license">license</h2> -<p>You should specify a license for your package so that people know how they are -permitted to use it, and any restrictions you're placing on it.</p> -<p>If you're using a common license such as BSD-2-Clause or MIT, add a -current SPDX license identifier for the license you're using, like this:</p> -<pre><code>{ "license" : "BSD-3-Clause" }</code></pre><p>You can check <a href="https://spdx.org/licenses/">the full list of SPDX license IDs</a>. -Ideally you should pick one that is -<a href="https://opensource.org/licenses/alphabetical">OSI</a> approved.</p> -<p>If your package is licensed under multiple common licenses, use an <a href="https://www.npmjs.com/package/spdx">SPDX license -expression syntax version 2.0 string</a>, like this:</p> -<pre><code>{ "license" : "(ISC OR GPL-3.0)" }</code></pre><p>If you are using a license that hasn't been assigned an SPDX identifier, or if -you are using a custom license, use a string value like this one:</p> -<pre><code>{ "license" : "SEE LICENSE IN <filename>" }</code></pre><p>Then include a file named <code><filename></code> at the top level of the package.</p> -<p>Some old packages used license objects or a "licenses" property containing an -array of license objects:</p> -<pre><code>// Not valid metadata -{ "license" : - { "type" : "ISC" - , "url" : "https://opensource.org/licenses/ISC" - } -} - -// Not valid metadata -{ "licenses" : - [ - { "type": "MIT" - , "url": "https://www.opensource.org/licenses/mit-license.php" - } - , { "type": "Apache-2.0" - , "url": "https://opensource.org/licenses/apache2.0.php" - } - ] -}</code></pre><p>Those styles are now deprecated. Instead, use SPDX expressions, like this:</p> -<pre><code>{ "license": "ISC" } - -{ "license": "(MIT OR Apache-2.0)" }</code></pre><p>Finally, if you do not wish to grant others the right to use a private or -unpublished package under any terms:</p> -<pre><code>{ "license": "UNLICENSED" }</code></pre><p>Consider also setting <code>"private": true</code> to prevent accidental publication.</p> -<h2 id="people-fields-author-contributors">people fields: author, contributors</h2> -<p>The "author" is one person. "contributors" is an array of people. A "person" -is an object with a "name" field and optionally "url" and "email", like this:</p> -<pre><code>{ "name" : "Barney Rubble" -, "email" : "b@rubble.com" -, "url" : "http://barnyrubble.tumblr.com/" -}</code></pre><p>Or you can shorten that all into a single string, and npm will parse it for you:</p> -<pre><code>"Barney Rubble <b@rubble.com> (http://barnyrubble.tumblr.com/)"</code></pre><p>Both email and url are optional either way.</p> -<p>npm also sets a top-level "maintainers" field with your npm user info.</p> -<h2 id="files">files</h2> -<p>The optional <code>files</code> field is an array of file patterns that describes -the entries to be included when your package is installed as a -dependency. File patterns follow a similar syntax to <code>.gitignore</code>, but -reversed: including a file, directory, or glob pattern (<code>*</code>, <code>**/*</code>, and such) -will make it so that file is included in the tarball when it's packed. Omitting -the field will make it default to <code>["*"]</code>, which means it will include all files.</p> -<p>Some special files and directories are also included or excluded regardless of -whether they exist in the <code>files</code> array (see below).</p> -<p>You can also provide a <code>.npmignore</code> file in the root of your package or -in subdirectories, which will keep files from being included. At the -root of your package it will not override the "files" field, but in -subdirectories it will. The <code>.npmignore</code> file works just like a -<code>.gitignore</code>. If there is a <code>.gitignore</code> file, and <code>.npmignore</code> is -missing, <code>.gitignore</code>'s contents will be used instead.</p> -<p>Files included with the "package.json#files" field <em>cannot</em> be excluded -through <code>.npmignore</code> or <code>.gitignore</code>.</p> -<p>Certain files are always included, regardless of settings:</p> -<ul> -<li><code>package.json</code></li> -<li><code><a href="../../doc/README.html">README</a></code></li> -<li><code>CHANGES</code> / <code>CHANGELOG</code> / <code>HISTORY</code></li> -<li><code>LICENSE</code> / <code>LICENCE</code></li> -<li><code>NOTICE</code></li> -<li>The file in the "main" field</li> -</ul> -<p><code><a href="../../doc/README.html">README</a></code>, <code>CHANGES</code>, <code>LICENSE</code> & <code>NOTICE</code> can have any case and extension.</p> -<p>Conversely, some files are always ignored:</p> -<ul> -<li><code>.git</code></li> -<li><code>CVS</code></li> -<li><code>.svn</code></li> -<li><code>.hg</code></li> -<li><code>.lock-wscript</code></li> -<li><code>.wafpickle-N</code></li> -<li><code>.*.swp</code></li> -<li><code>.DS_Store</code></li> -<li><code>._*</code></li> -<li><code>npm-debug.log</code></li> -<li><code>.npmrc</code></li> -<li><code>node_modules</code></li> -<li><code>config.gypi</code></li> -<li><code>*.orig</code></li> -<li><code>package-lock.json</code> (use shrinkwrap instead)</li> -</ul> -<h2 id="main">main</h2> -<p>The main field is a module ID that is the primary entry point to your program. -That is, if your package is named <code>foo</code>, and a user installs it, and then does -<code>require("foo")</code>, then your main module's exports object will be returned.</p> -<p>This should be a module ID relative to the root of your package folder.</p> -<p>For most modules, it makes the most sense to have a main script and often not -much else.</p> -<h2 id="browser">browser</h2> -<p>If your module is meant to be used client-side the browser field should be -used instead of the main field. This is helpful to hint users that it might -rely on primitives that aren't available in Node.js modules. (e.g. <code>window</code>)</p> -<h2 id="bin">bin</h2> -<p>A lot of packages have one or more executable files that they'd like to -install into the PATH. npm makes this pretty easy (in fact, it uses this -feature to install the "npm" executable.)</p> -<p>To use this, supply a <code>bin</code> field in your package.json which is a map of -command name to local file name. On install, npm will symlink that file into -<code>prefix/bin</code> for global installs, or <code>./node_modules/.bin/</code> for local -installs.</p> -<p>For example, myapp could have this:</p> -<pre><code>{ "bin" : { "myapp" : "./cli.js" } }</code></pre><p>So, when you install myapp, it'll create a symlink from the <code>cli.js</code> script to -<code>/usr/local/bin/myapp</code>.</p> -<p>If you have a single executable, and its name should be the name -of the package, then you can just supply it as a string. For example:</p> -<pre><code>{ "name": "my-program" -, "version": "1.2.5" -, "bin": "./path/to/program" }</code></pre><p>would be the same as this:</p> -<pre><code>{ "name": "my-program" -, "version": "1.2.5" -, "bin" : { "my-program" : "./path/to/program" } }</code></pre><p>Please make sure that your file(s) referenced in <code>bin</code> starts with -<code>#!/usr/bin/env node</code>, otherwise the scripts are started without the node -executable!</p> -<h2 id="man">man</h2> -<p>Specify either a single file or an array of filenames to put in place for the -<code>man</code> program to find.</p> -<p>If only a single file is provided, then it's installed such that it is the -result from <code>man <pkgname></code>, regardless of its actual filename. For example:</p> -<pre><code>{ "name" : "foo" -, "version" : "1.2.3" -, "description" : "A packaged foo fooer for fooing foos" -, "main" : "foo.js" -, "man" : "./man/doc.1" -}</code></pre><p>would link the <code>./man/doc.1</code> file in such that it is the target for <code>man foo</code></p> -<p>If the filename doesn't start with the package name, then it's prefixed. -So, this:</p> -<pre><code>{ "name" : "foo" -, "version" : "1.2.3" -, "description" : "A packaged foo fooer for fooing foos" -, "main" : "foo.js" -, "man" : [ "./man/foo.1", "./man/bar.1" ] -}</code></pre><p>will create files to do <code>man foo</code> and <code>man foo-bar</code>.</p> -<p>Man files must end with a number, and optionally a <code>.gz</code> suffix if they are -compressed. The number dictates which man section the file is installed into.</p> -<pre><code>{ "name" : "foo" -, "version" : "1.2.3" -, "description" : "A packaged foo fooer for fooing foos" -, "main" : "foo.js" -, "man" : [ "./man/foo.1", "./man/foo.2" ] -}</code></pre><p>will create entries for <code>man foo</code> and <code>man 2 foo</code></p> -<h2 id="directories">directories</h2> -<p>The CommonJS <a href="http://wiki.commonjs.org/wiki/Packages/1.0">Packages</a> spec details a -few ways that you can indicate the structure of your package using a <code>directories</code> -object. If you look at <a href="https://registry.npmjs.org/npm/latest">npm's package.json</a>, -you'll see that it has directories for doc, lib, and man.</p> -<p>In the future, this information may be used in other creative ways.</p> -<h3 id="directorieslib">directories.lib</h3> -<p>Tell people where the bulk of your library is. Nothing special is done -with the lib folder in any way, but it's useful meta info.</p> -<h3 id="directoriesbin">directories.bin</h3> -<p>If you specify a <code>bin</code> directory in <code>directories.bin</code>, all the files in -that folder will be added.</p> -<p>Because of the way the <code>bin</code> directive works, specifying both a -<code>bin</code> path and setting <code>directories.bin</code> is an error. If you want to -specify individual files, use <code>bin</code>, and for all the files in an -existing <code>bin</code> directory, use <code>directories.bin</code>.</p> -<h3 id="directoriesman">directories.man</h3> -<p>A folder that is full of man pages. Sugar to generate a "man" array by -walking the folder.</p> -<h3 id="directoriesdoc">directories.doc</h3> -<p>Put markdown files in here. Eventually, these will be displayed nicely, -maybe, someday.</p> -<h3 id="directoriesexample">directories.example</h3> -<p>Put example scripts in here. Someday, it might be exposed in some clever way.</p> -<h3 id="directoriestest">directories.test</h3> -<p>Put your tests in here. It is currently not exposed, but it might be in the -future.</p> -<h2 id="repository">repository</h2> -<p>Specify the place where your code lives. This is helpful for people who -want to contribute. If the git repo is on GitHub, then the <code>npm docs</code> -command will be able to find you.</p> -<p>Do it like this:</p> -<pre><code>"repository": { - "type" : "git", - "url" : "https://github.com/npm/cli.git" -} - -"repository": { - "type" : "svn", - "url" : "https://v8.googlecode.com/svn/trunk/" -}</code></pre><p>The URL should be a publicly available (perhaps read-only) url that can be handed -directly to a VCS program without any modification. It should not be a url to an -html project page that you put in your browser. It's for computers.</p> -<p>For GitHub, GitHub gist, Bitbucket, or GitLab repositories you can use the same -shortcut syntax you use for <code>npm install</code>:</p> -<pre><code>"repository": "npm/npm" - -"repository": "github:user/repo" - -"repository": "gist:11081aaa281" - -"repository": "bitbucket:user/repo" - -"repository": "gitlab:user/repo"</code></pre><h2 id="scripts">scripts</h2> -<p>The "scripts" property is a dictionary containing script commands that are run -at various times in the lifecycle of your package. The key is the lifecycle -event, and the value is the command to run at that point.</p> -<p>See <code><a href="../misc/npm-scripts.html">npm-scripts(7)</a></code> to find out more about writing package scripts.</p> -<h2 id="config">config</h2> -<p>A "config" object can be used to set configuration parameters used in package -scripts that persist across upgrades. For instance, if a package had the -following:</p> -<pre><code>{ "name" : "foo" -, "config" : { "port" : "8080" } }</code></pre><p>and then had a "start" command that then referenced the -<code>npm_package_config_port</code> environment variable, then the user could -override that by doing <code>npm config set foo:port 8001</code>.</p> -<p>See <code><a href="../misc/npm-config.html">npm-config(7)</a></code> and <code><a href="../misc/npm-scripts.html">npm-scripts(7)</a></code> for more on package -configs.</p> -<h2 id="dependencies">dependencies</h2> -<p>Dependencies are specified in a simple object that maps a package name to a -version range. The version range is a string which has one or more -space-separated descriptors. Dependencies can also be identified with a -tarball or git URL.</p> -<p><strong>Please do not put test harnesses or transpilers in your -<code>dependencies</code> object.</strong> See <code>devDependencies</code>, below.</p> -<p>See <a href="../misc/semver.html">semver(7)</a> for more details about specifying version ranges.</p> -<ul> -<li><code>version</code> Must match <code>version</code> exactly</li> -<li><code>>version</code> Must be greater than <code>version</code></li> -<li><code>>=version</code> etc</li> -<li><code><version</code></li> -<li><code><=version</code></li> -<li><code>~version</code> "Approximately equivalent to version" See <a href="../misc/semver.html">semver(7)</a></li> -<li><code>^version</code> "Compatible with version" See <a href="../misc/semver.html">semver(7)</a></li> -<li><code>1.2.x</code> 1.2.0, 1.2.1, etc., but not 1.3.0</li> -<li><code>http://...</code> See 'URLs as Dependencies' below</li> -<li><code>*</code> Matches any version</li> -<li><code>""</code> (just an empty string) Same as <code>*</code></li> -<li><code>version1 - version2</code> Same as <code>>=version1 <=version2</code>.</li> -<li><code>range1 || range2</code> Passes if either range1 or range2 are satisfied.</li> -<li><code>git...</code> See 'Git URLs as Dependencies' below</li> -<li><code>user/repo</code> See 'GitHub URLs' below</li> -<li><code>tag</code> A specific version tagged and published as <code>tag</code> See <code><a href="../cli/npm-dist-tag.html">npm-dist-tag(1)</a></code></li> -<li><code>path/path/path</code> See <a href="#local-paths">Local Paths</a> below</li> -</ul> -<p>For example, these are all valid:</p> -<pre><code>{ "dependencies" : - { "foo" : "1.0.0 - 2.9999.9999" - , "bar" : ">=1.0.2 <2.1.2" - , "baz" : ">1.0.2 <=2.3.4" - , "boo" : "2.0.1" - , "qux" : "<1.0.0 || >=2.3.1 <2.4.5 || >=2.5.2 <3.0.0" - , "asd" : "http://asdf.com/asdf.tar.gz" - , "til" : "~1.2" - , "elf" : "~1.2.3" - , "two" : "2.x" - , "thr" : "3.3.x" - , "lat" : "latest" - , "dyl" : "file:../dyl" - } -}</code></pre><h3 id="urls-as-dependencies">URLs as Dependencies</h3> -<p>You may specify a tarball URL in place of a version range.</p> -<p>This tarball will be downloaded and installed locally to your package at -install time.</p> -<h3 id="git-urls-as-dependencies">Git URLs as Dependencies</h3> -<p>Git urls are of the form:</p> -<pre><code><protocol>://[<user>[:<password>]@]<hostname>[:<port>][:][/]<path>[#<commit-ish> | #semver:<semver>]</code></pre><p><code><protocol></code> is one of <code>git</code>, <code>git+ssh</code>, <code>git+http</code>, <code>git+https</code>, or -<code>git+file</code>.</p> -<p>If <code>#<commit-ish></code> is provided, it will be used to clone exactly that -commit. If the commit-ish has the format <code>#semver:<semver></code>, <code><semver></code> can -be any valid semver range or exact version, and npm will look for any tags -or refs matching that range in the remote repository, much as it would for a -registry dependency. If neither <code>#<commit-ish></code> or <code>#semver:<semver></code> is -specified, then <code>master</code> is used.</p> -<p>Examples:</p> -<pre><code>git+ssh://git@github.com:npm/cli.git#v1.0.27 -git+ssh://git@github.com:npm/cli#semver:^5.0 -git+https://isaacs@github.com/npm/cli.git -git://github.com/npm/cli.git#v1.0.27</code></pre><h3 id="github-urls">GitHub URLs</h3> -<p>As of version 1.1.65, you can refer to GitHub urls as just "foo": -"user/foo-project". Just as with git URLs, a <code>commit-ish</code> suffix can be -included. For example:</p> -<pre><code>{ - "name": "foo", - "version": "0.0.0", - "dependencies": { - "express": "expressjs/express", - "mocha": "mochajs/mocha#4727d357ea", - "module": "user/repo#feature\/branch" - } -}</code></pre><h3 id="local-paths">Local Paths</h3> -<p>As of version 2.0.0 you can provide a path to a local directory that contains a -package. Local paths can be saved using <code>npm install -S</code> or -<code>npm install --save</code>, using any of these forms:</p> -<pre><code>../foo/bar -~/foo/bar -./foo/bar -/foo/bar</code></pre><p>in which case they will be normalized to a relative path and added to your -<code>package.json</code>. For example:</p> -<pre><code>{ - "name": "baz", - "dependencies": { - "bar": "file:../foo/bar" - } -}</code></pre><p>This feature is helpful for local offline development and creating -tests that require npm installing where you don't want to hit an -external server, but should not be used when publishing packages -to the public registry.</p> -<h2 id="devdependencies">devDependencies</h2> -<p>If someone is planning on downloading and using your module in their -program, then they probably don't want or need to download and build -the external test or documentation framework that you use.</p> -<p>In this case, it's best to map these additional items in a <code>devDependencies</code> -object.</p> -<p>These things will be installed when doing <code>npm link</code> or <code>npm install</code> -from the root of a package, and can be managed like any other npm -configuration param. See <code><a href="../misc/npm-config.html">npm-config(7)</a></code> for more on the topic.</p> -<p>For build steps that are not platform-specific, such as compiling -CoffeeScript or other languages to JavaScript, use the <code>prepare</code> -script to do this, and make the required package a devDependency.</p> -<p>For example:</p> -<pre><code>{ "name": "ethopia-waza", - "description": "a delightfully fruity coffee varietal", - "version": "1.2.3", - "devDependencies": { - "coffee-script": "~1.6.3" - }, - "scripts": { - "prepare": "coffee -o lib/ -c src/waza.coffee" - }, - "main": "lib/waza.js" -}</code></pre><p>The <code>prepare</code> script will be run before publishing, so that users -can consume the functionality without requiring them to compile it -themselves. In dev mode (ie, locally running <code>npm install</code>), it'll -run this script as well, so that you can test it easily.</p> -<h2 id="peerdependencies">peerDependencies</h2> -<p>In some cases, you want to express the compatibility of your package with a -host tool or library, while not necessarily doing a <code>require</code> of this host. -This is usually referred to as a <em>plugin</em>. Notably, your module may be exposing -a specific interface, expected and specified by the host documentation.</p> -<p>For example:</p> -<pre><code>{ - "name": "tea-latte", - "version": "1.3.5", - "peerDependencies": { - "tea": "2.x" - } -}</code></pre><p>This ensures your package <code>tea-latte</code> can be installed <em>along</em> with the second -major version of the host package <code>tea</code> only. <code>npm install tea-latte</code> could -possibly yield the following dependency graph:</p> -<pre><code>├── tea-latte@1.3.5 -└── tea@2.2.0</code></pre><p><strong>NOTE: npm versions 1 and 2 will automatically install <code>peerDependencies</code> if -they are not explicitly depended upon higher in the dependency tree. In the -next major version of npm (npm@3), this will no longer be the case. You will -receive a warning that the peerDependency is not installed instead.</strong> The -behavior in npms 1 & 2 was frequently confusing and could easily put you into -dependency hell, a situation that npm is designed to avoid as much as possible.</p> -<p>Trying to install another plugin with a conflicting requirement will cause an -error. For this reason, make sure your plugin requirement is as broad as -possible, and not to lock it down to specific patch versions.</p> -<p>Assuming the host complies with <a href="https://semver.org/">semver</a>, only changes in -the host package's major version will break your plugin. Thus, if you've worked -with every 1.x version of the host package, use <code>"^1.0"</code> or <code>"1.x"</code> to express -this. If you depend on features introduced in 1.5.2, use <code>">= 1.5.2 < 2"</code>.</p> -<h2 id="bundleddependencies">bundledDependencies</h2> -<p>This defines an array of package names that will be bundled when publishing -the package.</p> -<p>In cases where you need to preserve npm packages locally or have them -available through a single file download, you can bundle the packages in a -tarball file by specifying the package names in the <code>bundledDependencies</code> -array and executing <code>npm pack</code>.</p> -<p>For example:</p> -<p>If we define a package.json like this:</p> -<pre><code>{ - "name": "awesome-web-framework", - "version": "1.0.0", - "bundledDependencies": [ - "renderized", "super-streams" - ] -}</code></pre><p>we can obtain <code>awesome-web-framework-1.0.0.tgz</code> file by running <code>npm pack</code>. -This file contains the dependencies <code>renderized</code> and <code>super-streams</code> which -can be installed in a new project by executing <code>npm install -awesome-web-framework-1.0.0.tgz</code>.</p> -<p>If this is spelled <code>"bundleDependencies"</code>, then that is also honored.</p> -<h2 id="optionaldependencies">optionalDependencies</h2> -<p>If a dependency can be used, but you would like npm to proceed if it cannot be -found or fails to install, then you may put it in the <code>optionalDependencies</code> -object. This is a map of package name to version or url, just like the -<code>dependencies</code> object. The difference is that build failures do not cause -installation to fail.</p> -<p>It is still your program's responsibility to handle the lack of the -dependency. For example, something like this:</p> -<pre><code>try { - var foo = require('foo') - var fooVersion = require('foo/package.json').version -} catch (er) { - foo = null -} -if ( notGoodFooVersion(fooVersion) ) { - foo = null -} - -// .. then later in your program .. - -if (foo) { - foo.doFooThings() -}</code></pre><p>Entries in <code>optionalDependencies</code> will override entries of the same name in -<code>dependencies</code>, so it's usually best to only put in one place.</p> -<h2 id="engines">engines</h2> -<p>You can specify the version of node that your stuff works on:</p> -<pre><code>{ "engines" : { "node" : ">=0.10.3 <0.12" } }</code></pre><p>And, like with dependencies, if you don't specify the version (or if you -specify "*" as the version), then any version of node will do.</p> -<p>If you specify an "engines" field, then npm will require that "node" be -somewhere on that list. If "engines" is omitted, then npm will just assume -that it works on node.</p> -<p>You can also use the "engines" field to specify which versions of npm -are capable of properly installing your program. For example:</p> -<pre><code>{ "engines" : { "npm" : "~1.0.20" } }</code></pre><p>Unless the user has set the <code>engine-strict</code> config flag, this -field is advisory only and will only produce warnings when your package is installed as a dependency.</p> -<h2 id="enginestrict">engineStrict</h2> -<p><strong>This feature was removed in npm 3.0.0</strong></p> -<p>Prior to npm 3.0.0, this feature was used to treat this package as if the -user had set <code>engine-strict</code>. It is no longer used.</p> -<h2 id="os">os</h2> -<p>You can specify which operating systems your -module will run on:</p> -<pre><code>"os" : [ "darwin", "linux" ]</code></pre><p>You can also blacklist instead of whitelist operating systems, -just prepend the blacklisted os with a '!':</p> -<pre><code>"os" : [ "!win32" ]</code></pre><p>The host operating system is determined by <code>process.platform</code></p> -<p>It is allowed to both blacklist, and whitelist, although there isn't any -good reason to do this.</p> -<h2 id="cpu">cpu</h2> -<p>If your code only runs on certain cpu architectures, -you can specify which ones.</p> -<pre><code>"cpu" : [ "x64", "ia32" ]</code></pre><p>Like the <code>os</code> option, you can also blacklist architectures:</p> -<pre><code>"cpu" : [ "!arm", "!mips" ]</code></pre><p>The host architecture is determined by <code>process.arch</code></p> -<h2 id="preferglobal">preferGlobal</h2> -<p><strong>DEPRECATED</strong></p> -<p>This option used to trigger an npm warning, but it will no longer warn. It is -purely there for informational purposes. It is now recommended that you install -any binaries as local devDependencies wherever possible.</p> -<h2 id="private">private</h2> -<p>If you set <code>"private": true</code> in your package.json, then npm will refuse -to publish it.</p> -<p>This is a way to prevent accidental publication of private repositories. If -you would like to ensure that a given package is only ever published to a -specific registry (for example, an internal registry), then use the -<code>publishConfig</code> dictionary described below to override the <code>registry</code> config -param at publish-time.</p> -<h2 id="publishconfig">publishConfig</h2> -<p>This is a set of config values that will be used at publish-time. It's -especially handy if you want to set the tag, registry or access, so that -you can ensure that a given package is not tagged with "latest", published -to the global public registry or that a scoped module is private by default.</p> -<p>Any config values can be overridden, but only "tag", "registry" and "access" -probably matter for the purposes of publishing.</p> -<p>See <code><a href="../misc/npm-config.html">npm-config(7)</a></code> to see the list of config options that can be -overridden.</p> -<h2 id="default-values">DEFAULT VALUES</h2> -<p>npm will default some values based on package contents.</p> -<ul> -<li><p><code>"scripts": {"start": "node server.js"}</code></p> -<p>If there is a <code>server.js</code> file in the root of your package, then npm -will default the <code>start</code> command to <code>node server.js</code>.</p> -</li> -<li><p><code>"scripts":{"install": "node-gyp rebuild"}</code></p> -<p>If there is a <code>binding.gyp</code> file in the root of your package and you have not defined an <code>install</code> or <code>preinstall</code> script, npm will -default the <code>install</code> command to compile using node-gyp.</p> -</li> -<li><p><code>"contributors": [...]</code></p> -<p>If there is an <code>AUTHORS</code> file in the root of your package, npm will -treat each line as a <code>Name <email> (url)</code> format, where email and url -are optional. Lines which start with a <code>#</code> or are blank, will be -ignored.</p> -</li> -</ul> -<h2 id="see-also">SEE ALSO</h2> -<ul> -<li><a href="../misc/semver.html">semver(7)</a></li> -<li><a href="../cli/npm-init.html">npm-init(1)</a></li> -<li><a href="../cli/npm-version.html">npm-version(1)</a></li> -<li><a href="../cli/npm-config.html">npm-config(1)</a></li> -<li><a href="../misc/npm-config.html">npm-config(7)</a></li> -<li><a href="../cli/npm-help.html">npm-help(1)</a></li> -<li><a href="../cli/npm-install.html">npm-install(1)</a></li> -<li><a href="../cli/npm-publish.html">npm-publish(1)</a></li> -<li><a href="../cli/npm-uninstall.html">npm-uninstall(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.json — npm@6.7.0</p> - diff --git a/deps/node/deps/npm/html/doc/files/npm-package-locks.html b/deps/node/deps/npm/html/doc/files/npm-package-locks.html deleted file mode 100644 index 6e273ed3..00000000 --- a/deps/node/deps/npm/html/doc/files/npm-package-locks.html +++ /dev/null @@ -1,157 +0,0 @@ -<!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 <a href="mailto:B@0.0.2">B@0.0.2</a> 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 <a href="mailto:B@0.0.1">B@0.0.1</a>. 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, any 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> -<h3 id="resolving-lockfile-conflicts">Resolving lockfile conflicts</h3> -<p>Occasionally, two separate npm install will create package locks that cause -merge conflicts in source control systems. As of <code>npm@5.7.0</code>, these conflicts -can be resolved by manually fixing any <code>package.json</code> conflicts, and then -running <code>npm install [--package-lock-only]</code> again. npm will automatically -resolve any conflicts for you and write a merged package lock that includes all -the dependencies from both branches in a reasonable tree. If -<code>--package-lock-only</code> is provided, it will do this without also modifying your -local <code>node_modules/</code>.</p> -<p>To make this process seamless on git, consider installing -<a href="https://npm.im/npm-merge-driver"><code>npm-merge-driver</code></a>, which will teach git how -to do this itself without any user interaction. In short: <code>$ npx -npm-merge-driver install -g</code> will let you do this, and even works with -pre-<code>npm@5.7.0</code> versions of npm 5, albeit a bit more noisily. Note that if -<code>package.json</code> itself conflicts, you will have to resolve that by hand and run -<code>npm install</code> manually, even with the merge driver.</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@6.7.0</p> diff --git a/deps/node/deps/npm/html/doc/files/npm-shrinkwrap.json.html b/deps/node/deps/npm/html/doc/files/npm-shrinkwrap.json.html deleted file mode 100644 index 70316f15..00000000 --- a/deps/node/deps/npm/html/doc/files/npm-shrinkwrap.json.html +++ /dev/null @@ -1,45 +0,0 @@ -<!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-shrinkwrap.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-shrinkwrap.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@6.7.0</p> diff --git a/deps/node/deps/npm/html/doc/files/npmrc.html b/deps/node/deps/npm/html/doc/files/npmrc.html deleted file mode 100644 index 9b34b7a1..00000000 --- a/deps/node/deps/npm/html/doc/files/npmrc.html +++ /dev/null @@ -1,86 +0,0 @@ -<!doctype html> -<html> - <title>npmrc</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/npmrc.html"> - <script async=true src="../../static/toc.js"></script> - - <body> - <div id="wrapper"> - -<h1><a href="../files/npmrc.html">npmrc</a></h1> <p>The npm config files</p> -<h2 id="description">DESCRIPTION</h2> -<p>npm gets its config settings from the command line, environment -variables, and <code>npmrc</code> files.</p> -<p>The <code>npm config</code> command can be used to update and edit the contents -of the user and global npmrc files.</p> -<p>For a list of available configuration options, see <a href="../misc/npm-config.html">npm-config(7)</a>.</p> -<h2 id="files">FILES</h2> -<p>The four relevant files are:</p> -<ul> -<li>per-project config file (/path/to/my/project/.npmrc)</li> -<li>per-user config file (~/.npmrc)</li> -<li>global config file ($PREFIX/etc/npmrc)</li> -<li>npm builtin config file (/path/to/npm/npmrc)</li> -</ul> -<p>All npm config files are an ini-formatted list of <code>key = value</code> -parameters. Environment variables can be replaced using -<code>${VARIABLE_NAME}</code>. For example:</p> -<pre><code>prefix = ${HOME}/.npm-packages</code></pre><p>Each of these files is loaded, and config options are resolved in -priority order. For example, a setting in the userconfig file would -override the setting in the globalconfig file.</p> -<p>Array values are specified by adding "[]" after the key name. For -example:</p> -<pre><code>key[] = "first value" -key[] = "second value"</code></pre><h4 id="comments">Comments</h4> -<p>Lines in <code>.npmrc</code> files are interpreted as comments when they begin with a <code>;</code> or <code>#</code> character. <code>.npmrc</code> files are parsed by <a href="https://github.com/npm/ini">npm/ini</a>, which specifies this comment syntax.</p> -<p>For example:</p> -<pre><code># last modified: 01 Jan 2016 -; Set a new registry for a scoped package -@myscope:registry=https://mycustomregistry.example.org</code></pre><h3 id="per-project-config-file">Per-project config file</h3> -<p>When working locally in a project, a <code>.npmrc</code> file in the root of the -project (ie, a sibling of <code>node_modules</code> and <code>package.json</code>) will set -config values specific to this project.</p> -<p>Note that this only applies to the root of the project that you're -running npm in. It has no effect when your module is published. For -example, you can't publish a module that forces itself to install -globally, or in a different location.</p> -<p>Additionally, this file is not read in global mode, such as when running -<code>npm install -g</code>.</p> -<h3 id="per-user-config-file">Per-user config file</h3> -<p><code>$HOME/.npmrc</code> (or the <code>userconfig</code> param, if set in the environment -or on the command line)</p> -<h3 id="global-config-file">Global config file</h3> -<p><code>$PREFIX/etc/npmrc</code> (or the <code>globalconfig</code> param, if set above): -This file is an ini-file formatted list of <code>key = value</code> parameters. -Environment variables can be replaced as above.</p> -<h3 id="built-in-config-file">Built-in config file</h3> -<p><code>path/to/npm/itself/npmrc</code></p> -<p>This is an unchangeable "builtin" configuration file that npm keeps -consistent across updates. Set fields in here using the <code>./configure</code> -script that comes with npm. This is primarily for distribution -maintainers to override default configs in a standard and consistent -manner.</p> -<h2 id="see-also">SEE ALSO</h2> -<ul> -<li><a href="../files/npm-folders.html">npm-folders(5)</a></li> -<li><a href="../cli/npm-config.html">npm-config(1)</a></li> -<li><a href="../misc/npm-config.html">npm-config(7)</a></li> -<li><a href="../files/package.json.html">package.json(5)</a></li> -<li><a href="../cli/npm.html">npm(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">npmrc — npm@6.7.0</p> - diff --git a/deps/node/deps/npm/html/doc/files/package-lock.json.html b/deps/node/deps/npm/html/doc/files/package-lock.json.html deleted file mode 100644 index 1d639944..00000000 --- a/deps/node/deps/npm/html/doc/files/package-lock.json.html +++ /dev/null @@ -1,133 +0,0 @@ -<!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>package.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-1">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="requires">requires</h4> -<p>This is a mapping of module name to version. This is a list of everything -this module requires, regardless of where it will be installed. The version -should match via normal matching rules a dependency either in our -<code>dependencies</code> or in a level higher than us.</p> -<h4 id="dependencies-1">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/npm-shrinkwrap.json.html">npm-shrinkwrap.json(5)</a></li> -<li><a href="../files/npm-package-locks.html">npm-package-locks(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@6.7.0</p> diff --git a/deps/node/deps/npm/html/doc/files/package.json.html b/deps/node/deps/npm/html/doc/files/package.json.html deleted file mode 100644 index 751bbebd..00000000 --- a/deps/node/deps/npm/html/doc/files/package.json.html +++ /dev/null @@ -1,578 +0,0 @@ -<!doctype html> -<html> - <title>package.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.json.html"> - <script async=true src="../../static/toc.js"></script> - - <body> - <div id="wrapper"> - -<h1><a href="../files/package.json.html">package.json</a></h1> <p>Specifics of npm's package.json handling</p> -<h2 id="description">DESCRIPTION</h2> -<p>This document is all you need to know about what's required in your package.json -file. It must be actual JSON, not just a JavaScript object literal.</p> -<p>A lot of the behavior described in this document is affected by the config -settings described in <code><a href="../misc/npm-config.html">npm-config(7)</a></code>.</p> -<h2 id="name">name</h2> -<p>If you plan to publish your package, the <em>most</em> important things in your -package.json are the name and version fields as they will be required. The name -and version together form an identifier that is assumed to be completely unique. -Changes to the package should come along with changes to the version. If you don't -plan to publish your package, the name and version fields are optional.</p> -<p>The name is what your thing is called.</p> -<p>Some rules:</p> -<ul> -<li>The name must be less than or equal to 214 characters. This includes the scope for -scoped packages.</li> -<li>The name can't start with a dot or an underscore.</li> -<li>New packages must not have uppercase letters in the name.</li> -<li>The name ends up being part of a URL, an argument on the command line, and a -folder name. Therefore, the name can't contain any non-URL-safe characters.</li> -</ul> -<p>Some tips:</p> -<ul> -<li>Don't use the same name as a core Node module.</li> -<li>Don't put "js" or "node" in the name. It's assumed that it's js, since you're -writing a package.json file, and you can specify the engine using the "engines" -field. (See below.)</li> -<li>The name will probably be passed as an argument to require(), so it should -be something short, but also reasonably descriptive.</li> -<li>You may want to check the npm registry to see if there's something by that name -already, before you get too attached to it. <a href="https://www.npmjs.com/">https://www.npmjs.com/</a></li> -</ul> -<p>A name can be optionally prefixed by a scope, e.g. <code>@myorg/mypackage</code>. See -<code><a href="../misc/npm-scope.html">npm-scope(7)</a></code> for more detail.</p> -<h2 id="version">version</h2> -<p>If you plan to publish your package, the <em>most</em> important things in your -package.json are the name and version fields as they will be required. The name -and version together form an identifier that is assumed to be completely unique. -Changes to the package should come along with changes to the version. If you don't -plan to publish your package, the name and version fields are optional.</p> -<p>Version must be parseable by -<a href="https://github.com/isaacs/node-semver">node-semver</a>, which is bundled -with npm as a dependency. (<code>npm install semver</code> to use it yourself.)</p> -<p>More on version numbers and ranges at <a href="../misc/semver.html">semver(7)</a>.</p> -<h2 id="description-1">description</h2> -<p>Put a description in it. It's a string. This helps people discover your -package, as it's listed in <code>npm search</code>.</p> -<h2 id="keywords">keywords</h2> -<p>Put keywords in it. It's an array of strings. This helps people -discover your package as it's listed in <code>npm search</code>.</p> -<h2 id="homepage">homepage</h2> -<p>The url to the project homepage.</p> -<p>Example:</p> -<pre><code>"homepage": "https://github.com/owner/project#readme"</code></pre><h2 id="bugs">bugs</h2> -<p>The url to your project's issue tracker and / or the email address to which -issues should be reported. These are helpful for people who encounter issues -with your package.</p> -<p>It should look like this:</p> -<pre><code>{ "url" : "https://github.com/owner/project/issues" -, "email" : "project@hostname.com" -}</code></pre><p>You can specify either one or both values. If you want to provide only a url, -you can specify the value for "bugs" as a simple string instead of an object.</p> -<p>If a url is provided, it will be used by the <code>npm bugs</code> command.</p> -<h2 id="license">license</h2> -<p>You should specify a license for your package so that people know how they are -permitted to use it, and any restrictions you're placing on it.</p> -<p>If you're using a common license such as BSD-2-Clause or MIT, add a -current SPDX license identifier for the license you're using, like this:</p> -<pre><code>{ "license" : "BSD-3-Clause" }</code></pre><p>You can check <a href="https://spdx.org/licenses/">the full list of SPDX license IDs</a>. -Ideally you should pick one that is -<a href="https://opensource.org/licenses/alphabetical">OSI</a> approved.</p> -<p>If your package is licensed under multiple common licenses, use an <a href="https://www.npmjs.com/package/spdx">SPDX license -expression syntax version 2.0 string</a>, like this:</p> -<pre><code>{ "license" : "(ISC OR GPL-3.0)" }</code></pre><p>If you are using a license that hasn't been assigned an SPDX identifier, or if -you are using a custom license, use a string value like this one:</p> -<pre><code>{ "license" : "SEE LICENSE IN <filename>" }</code></pre><p>Then include a file named <code><filename></code> at the top level of the package.</p> -<p>Some old packages used license objects or a "licenses" property containing an -array of license objects:</p> -<pre><code>// Not valid metadata -{ "license" : - { "type" : "ISC" - , "url" : "https://opensource.org/licenses/ISC" - } -} - -// Not valid metadata -{ "licenses" : - [ - { "type": "MIT" - , "url": "https://www.opensource.org/licenses/mit-license.php" - } - , { "type": "Apache-2.0" - , "url": "https://opensource.org/licenses/apache2.0.php" - } - ] -}</code></pre><p>Those styles are now deprecated. Instead, use SPDX expressions, like this:</p> -<pre><code>{ "license": "ISC" } - -{ "license": "(MIT OR Apache-2.0)" }</code></pre><p>Finally, if you do not wish to grant others the right to use a private or -unpublished package under any terms:</p> -<pre><code>{ "license": "UNLICENSED" }</code></pre><p>Consider also setting <code>"private": true</code> to prevent accidental publication.</p> -<h2 id="people-fields-author-contributors">people fields: author, contributors</h2> -<p>The "author" is one person. "contributors" is an array of people. A "person" -is an object with a "name" field and optionally "url" and "email", like this:</p> -<pre><code>{ "name" : "Barney Rubble" -, "email" : "b@rubble.com" -, "url" : "http://barnyrubble.tumblr.com/" -}</code></pre><p>Or you can shorten that all into a single string, and npm will parse it for you:</p> -<pre><code>"Barney Rubble <b@rubble.com> (http://barnyrubble.tumblr.com/)"</code></pre><p>Both email and url are optional either way.</p> -<p>npm also sets a top-level "maintainers" field with your npm user info.</p> -<h2 id="files">files</h2> -<p>The optional <code>files</code> field is an array of file patterns that describes -the entries to be included when your package is installed as a -dependency. File patterns follow a similar syntax to <code>.gitignore</code>, but -reversed: including a file, directory, or glob pattern (<code>*</code>, <code>**/*</code>, and such) -will make it so that file is included in the tarball when it's packed. Omitting -the field will make it default to <code>["*"]</code>, which means it will include all files.</p> -<p>Some special files and directories are also included or excluded regardless of -whether they exist in the <code>files</code> array (see below).</p> -<p>You can also provide a <code>.npmignore</code> file in the root of your package or -in subdirectories, which will keep files from being included. At the -root of your package it will not override the "files" field, but in -subdirectories it will. The <code>.npmignore</code> file works just like a -<code>.gitignore</code>. If there is a <code>.gitignore</code> file, and <code>.npmignore</code> is -missing, <code>.gitignore</code>'s contents will be used instead.</p> -<p>Files included with the "package.json#files" field <em>cannot</em> be excluded -through <code>.npmignore</code> or <code>.gitignore</code>.</p> -<p>Certain files are always included, regardless of settings:</p> -<ul> -<li><code>package.json</code></li> -<li><code><a href="../../doc/README.html">README</a></code></li> -<li><code>CHANGES</code> / <code>CHANGELOG</code> / <code>HISTORY</code></li> -<li><code>LICENSE</code> / <code>LICENCE</code></li> -<li><code>NOTICE</code></li> -<li>The file in the "main" field</li> -</ul> -<p><code><a href="../../doc/README.html">README</a></code>, <code>CHANGES</code>, <code>LICENSE</code> & <code>NOTICE</code> can have any case and extension.</p> -<p>Conversely, some files are always ignored:</p> -<ul> -<li><code>.git</code></li> -<li><code>CVS</code></li> -<li><code>.svn</code></li> -<li><code>.hg</code></li> -<li><code>.lock-wscript</code></li> -<li><code>.wafpickle-N</code></li> -<li><code>.*.swp</code></li> -<li><code>.DS_Store</code></li> -<li><code>._*</code></li> -<li><code>npm-debug.log</code></li> -<li><code>.npmrc</code></li> -<li><code>node_modules</code></li> -<li><code>config.gypi</code></li> -<li><code>*.orig</code></li> -<li><code>package-lock.json</code> (use shrinkwrap instead)</li> -</ul> -<h2 id="main">main</h2> -<p>The main field is a module ID that is the primary entry point to your program. -That is, if your package is named <code>foo</code>, and a user installs it, and then does -<code>require("foo")</code>, then your main module's exports object will be returned.</p> -<p>This should be a module ID relative to the root of your package folder.</p> -<p>For most modules, it makes the most sense to have a main script and often not -much else.</p> -<h2 id="browser">browser</h2> -<p>If your module is meant to be used client-side the browser field should be -used instead of the main field. This is helpful to hint users that it might -rely on primitives that aren't available in Node.js modules. (e.g. <code>window</code>)</p> -<h2 id="bin">bin</h2> -<p>A lot of packages have one or more executable files that they'd like to -install into the PATH. npm makes this pretty easy (in fact, it uses this -feature to install the "npm" executable.)</p> -<p>To use this, supply a <code>bin</code> field in your package.json which is a map of -command name to local file name. On install, npm will symlink that file into -<code>prefix/bin</code> for global installs, or <code>./node_modules/.bin/</code> for local -installs.</p> -<p>For example, myapp could have this:</p> -<pre><code>{ "bin" : { "myapp" : "./cli.js" } }</code></pre><p>So, when you install myapp, it'll create a symlink from the <code>cli.js</code> script to -<code>/usr/local/bin/myapp</code>.</p> -<p>If you have a single executable, and its name should be the name -of the package, then you can just supply it as a string. For example:</p> -<pre><code>{ "name": "my-program" -, "version": "1.2.5" -, "bin": "./path/to/program" }</code></pre><p>would be the same as this:</p> -<pre><code>{ "name": "my-program" -, "version": "1.2.5" -, "bin" : { "my-program" : "./path/to/program" } }</code></pre><p>Please make sure that your file(s) referenced in <code>bin</code> starts with -<code>#!/usr/bin/env node</code>, otherwise the scripts are started without the node -executable!</p> -<h2 id="man">man</h2> -<p>Specify either a single file or an array of filenames to put in place for the -<code>man</code> program to find.</p> -<p>If only a single file is provided, then it's installed such that it is the -result from <code>man <pkgname></code>, regardless of its actual filename. For example:</p> -<pre><code>{ "name" : "foo" -, "version" : "1.2.3" -, "description" : "A packaged foo fooer for fooing foos" -, "main" : "foo.js" -, "man" : "./man/doc.1" -}</code></pre><p>would link the <code>./man/doc.1</code> file in such that it is the target for <code>man foo</code></p> -<p>If the filename doesn't start with the package name, then it's prefixed. -So, this:</p> -<pre><code>{ "name" : "foo" -, "version" : "1.2.3" -, "description" : "A packaged foo fooer for fooing foos" -, "main" : "foo.js" -, "man" : [ "./man/foo.1", "./man/bar.1" ] -}</code></pre><p>will create files to do <code>man foo</code> and <code>man foo-bar</code>.</p> -<p>Man files must end with a number, and optionally a <code>.gz</code> suffix if they are -compressed. The number dictates which man section the file is installed into.</p> -<pre><code>{ "name" : "foo" -, "version" : "1.2.3" -, "description" : "A packaged foo fooer for fooing foos" -, "main" : "foo.js" -, "man" : [ "./man/foo.1", "./man/foo.2" ] -}</code></pre><p>will create entries for <code>man foo</code> and <code>man 2 foo</code></p> -<h2 id="directories">directories</h2> -<p>The CommonJS <a href="http://wiki.commonjs.org/wiki/Packages/1.0">Packages</a> spec details a -few ways that you can indicate the structure of your package using a <code>directories</code> -object. If you look at <a href="https://registry.npmjs.org/npm/latest">npm's package.json</a>, -you'll see that it has directories for doc, lib, and man.</p> -<p>In the future, this information may be used in other creative ways.</p> -<h3 id="directorieslib">directories.lib</h3> -<p>Tell people where the bulk of your library is. Nothing special is done -with the lib folder in any way, but it's useful meta info.</p> -<h3 id="directoriesbin">directories.bin</h3> -<p>If you specify a <code>bin</code> directory in <code>directories.bin</code>, all the files in -that folder will be added.</p> -<p>Because of the way the <code>bin</code> directive works, specifying both a -<code>bin</code> path and setting <code>directories.bin</code> is an error. If you want to -specify individual files, use <code>bin</code>, and for all the files in an -existing <code>bin</code> directory, use <code>directories.bin</code>.</p> -<h3 id="directoriesman">directories.man</h3> -<p>A folder that is full of man pages. Sugar to generate a "man" array by -walking the folder.</p> -<h3 id="directoriesdoc">directories.doc</h3> -<p>Put markdown files in here. Eventually, these will be displayed nicely, -maybe, someday.</p> -<h3 id="directoriesexample">directories.example</h3> -<p>Put example scripts in here. Someday, it might be exposed in some clever way.</p> -<h3 id="directoriestest">directories.test</h3> -<p>Put your tests in here. It is currently not exposed, but it might be in the -future.</p> -<h2 id="repository">repository</h2> -<p>Specify the place where your code lives. This is helpful for people who -want to contribute. If the git repo is on GitHub, then the <code>npm docs</code> -command will be able to find you.</p> -<p>Do it like this:</p> -<pre><code>"repository": { - "type" : "git", - "url" : "https://github.com/npm/cli.git" -} - -"repository": { - "type" : "svn", - "url" : "https://v8.googlecode.com/svn/trunk/" -}</code></pre><p>The URL should be a publicly available (perhaps read-only) url that can be handed -directly to a VCS program without any modification. It should not be a url to an -html project page that you put in your browser. It's for computers.</p> -<p>For GitHub, GitHub gist, Bitbucket, or GitLab repositories you can use the same -shortcut syntax you use for <code>npm install</code>:</p> -<pre><code>"repository": "npm/npm" - -"repository": "github:user/repo" - -"repository": "gist:11081aaa281" - -"repository": "bitbucket:user/repo" - -"repository": "gitlab:user/repo"</code></pre><h2 id="scripts">scripts</h2> -<p>The "scripts" property is a dictionary containing script commands that are run -at various times in the lifecycle of your package. The key is the lifecycle -event, and the value is the command to run at that point.</p> -<p>See <code><a href="../misc/npm-scripts.html">npm-scripts(7)</a></code> to find out more about writing package scripts.</p> -<h2 id="config">config</h2> -<p>A "config" object can be used to set configuration parameters used in package -scripts that persist across upgrades. For instance, if a package had the -following:</p> -<pre><code>{ "name" : "foo" -, "config" : { "port" : "8080" } }</code></pre><p>and then had a "start" command that then referenced the -<code>npm_package_config_port</code> environment variable, then the user could -override that by doing <code>npm config set foo:port 8001</code>.</p> -<p>See <code><a href="../misc/npm-config.html">npm-config(7)</a></code> and <code><a href="../misc/npm-scripts.html">npm-scripts(7)</a></code> for more on package -configs.</p> -<h2 id="dependencies">dependencies</h2> -<p>Dependencies are specified in a simple object that maps a package name to a -version range. The version range is a string which has one or more -space-separated descriptors. Dependencies can also be identified with a -tarball or git URL.</p> -<p><strong>Please do not put test harnesses or transpilers in your -<code>dependencies</code> object.</strong> See <code>devDependencies</code>, below.</p> -<p>See <a href="../misc/semver.html">semver(7)</a> for more details about specifying version ranges.</p> -<ul> -<li><code>version</code> Must match <code>version</code> exactly</li> -<li><code>>version</code> Must be greater than <code>version</code></li> -<li><code>>=version</code> etc</li> -<li><code><version</code></li> -<li><code><=version</code></li> -<li><code>~version</code> "Approximately equivalent to version" See <a href="../misc/semver.html">semver(7)</a></li> -<li><code>^version</code> "Compatible with version" See <a href="../misc/semver.html">semver(7)</a></li> -<li><code>1.2.x</code> 1.2.0, 1.2.1, etc., but not 1.3.0</li> -<li><code>http://...</code> See 'URLs as Dependencies' below</li> -<li><code>*</code> Matches any version</li> -<li><code>""</code> (just an empty string) Same as <code>*</code></li> -<li><code>version1 - version2</code> Same as <code>>=version1 <=version2</code>.</li> -<li><code>range1 || range2</code> Passes if either range1 or range2 are satisfied.</li> -<li><code>git...</code> See 'Git URLs as Dependencies' below</li> -<li><code>user/repo</code> See 'GitHub URLs' below</li> -<li><code>tag</code> A specific version tagged and published as <code>tag</code> See <code><a href="../cli/npm-dist-tag.html">npm-dist-tag(1)</a></code></li> -<li><code>path/path/path</code> See <a href="#local-paths">Local Paths</a> below</li> -</ul> -<p>For example, these are all valid:</p> -<pre><code>{ "dependencies" : - { "foo" : "1.0.0 - 2.9999.9999" - , "bar" : ">=1.0.2 <2.1.2" - , "baz" : ">1.0.2 <=2.3.4" - , "boo" : "2.0.1" - , "qux" : "<1.0.0 || >=2.3.1 <2.4.5 || >=2.5.2 <3.0.0" - , "asd" : "http://asdf.com/asdf.tar.gz" - , "til" : "~1.2" - , "elf" : "~1.2.3" - , "two" : "2.x" - , "thr" : "3.3.x" - , "lat" : "latest" - , "dyl" : "file:../dyl" - } -}</code></pre><h3 id="urls-as-dependencies">URLs as Dependencies</h3> -<p>You may specify a tarball URL in place of a version range.</p> -<p>This tarball will be downloaded and installed locally to your package at -install time.</p> -<h3 id="git-urls-as-dependencies">Git URLs as Dependencies</h3> -<p>Git urls are of the form:</p> -<pre><code><protocol>://[<user>[:<password>]@]<hostname>[:<port>][:][/]<path>[#<commit-ish> | #semver:<semver>]</code></pre><p><code><protocol></code> is one of <code>git</code>, <code>git+ssh</code>, <code>git+http</code>, <code>git+https</code>, or -<code>git+file</code>.</p> -<p>If <code>#<commit-ish></code> is provided, it will be used to clone exactly that -commit. If the commit-ish has the format <code>#semver:<semver></code>, <code><semver></code> can -be any valid semver range or exact version, and npm will look for any tags -or refs matching that range in the remote repository, much as it would for a -registry dependency. If neither <code>#<commit-ish></code> or <code>#semver:<semver></code> is -specified, then <code>master</code> is used.</p> -<p>Examples:</p> -<pre><code>git+ssh://git@github.com:npm/cli.git#v1.0.27 -git+ssh://git@github.com:npm/cli#semver:^5.0 -git+https://isaacs@github.com/npm/cli.git -git://github.com/npm/cli.git#v1.0.27</code></pre><h3 id="github-urls">GitHub URLs</h3> -<p>As of version 1.1.65, you can refer to GitHub urls as just "foo": -"user/foo-project". Just as with git URLs, a <code>commit-ish</code> suffix can be -included. For example:</p> -<pre><code>{ - "name": "foo", - "version": "0.0.0", - "dependencies": { - "express": "expressjs/express", - "mocha": "mochajs/mocha#4727d357ea", - "module": "user/repo#feature\/branch" - } -}</code></pre><h3 id="local-paths">Local Paths</h3> -<p>As of version 2.0.0 you can provide a path to a local directory that contains a -package. Local paths can be saved using <code>npm install -S</code> or -<code>npm install --save</code>, using any of these forms:</p> -<pre><code>../foo/bar -~/foo/bar -./foo/bar -/foo/bar</code></pre><p>in which case they will be normalized to a relative path and added to your -<code>package.json</code>. For example:</p> -<pre><code>{ - "name": "baz", - "dependencies": { - "bar": "file:../foo/bar" - } -}</code></pre><p>This feature is helpful for local offline development and creating -tests that require npm installing where you don't want to hit an -external server, but should not be used when publishing packages -to the public registry.</p> -<h2 id="devdependencies">devDependencies</h2> -<p>If someone is planning on downloading and using your module in their -program, then they probably don't want or need to download and build -the external test or documentation framework that you use.</p> -<p>In this case, it's best to map these additional items in a <code>devDependencies</code> -object.</p> -<p>These things will be installed when doing <code>npm link</code> or <code>npm install</code> -from the root of a package, and can be managed like any other npm -configuration param. See <code><a href="../misc/npm-config.html">npm-config(7)</a></code> for more on the topic.</p> -<p>For build steps that are not platform-specific, such as compiling -CoffeeScript or other languages to JavaScript, use the <code>prepare</code> -script to do this, and make the required package a devDependency.</p> -<p>For example:</p> -<pre><code>{ "name": "ethopia-waza", - "description": "a delightfully fruity coffee varietal", - "version": "1.2.3", - "devDependencies": { - "coffee-script": "~1.6.3" - }, - "scripts": { - "prepare": "coffee -o lib/ -c src/waza.coffee" - }, - "main": "lib/waza.js" -}</code></pre><p>The <code>prepare</code> script will be run before publishing, so that users -can consume the functionality without requiring them to compile it -themselves. In dev mode (ie, locally running <code>npm install</code>), it'll -run this script as well, so that you can test it easily.</p> -<h2 id="peerdependencies">peerDependencies</h2> -<p>In some cases, you want to express the compatibility of your package with a -host tool or library, while not necessarily doing a <code>require</code> of this host. -This is usually referred to as a <em>plugin</em>. Notably, your module may be exposing -a specific interface, expected and specified by the host documentation.</p> -<p>For example:</p> -<pre><code>{ - "name": "tea-latte", - "version": "1.3.5", - "peerDependencies": { - "tea": "2.x" - } -}</code></pre><p>This ensures your package <code>tea-latte</code> can be installed <em>along</em> with the second -major version of the host package <code>tea</code> only. <code>npm install tea-latte</code> could -possibly yield the following dependency graph:</p> -<pre><code>├── tea-latte@1.3.5 -└── tea@2.2.0</code></pre><p><strong>NOTE: npm versions 1 and 2 will automatically install <code>peerDependencies</code> if -they are not explicitly depended upon higher in the dependency tree. In the -next major version of npm (npm@3), this will no longer be the case. You will -receive a warning that the peerDependency is not installed instead.</strong> The -behavior in npms 1 & 2 was frequently confusing and could easily put you into -dependency hell, a situation that npm is designed to avoid as much as possible.</p> -<p>Trying to install another plugin with a conflicting requirement will cause an -error. For this reason, make sure your plugin requirement is as broad as -possible, and not to lock it down to specific patch versions.</p> -<p>Assuming the host complies with <a href="https://semver.org/">semver</a>, only changes in -the host package's major version will break your plugin. Thus, if you've worked -with every 1.x version of the host package, use <code>"^1.0"</code> or <code>"1.x"</code> to express -this. If you depend on features introduced in 1.5.2, use <code>">= 1.5.2 < 2"</code>.</p> -<h2 id="bundleddependencies">bundledDependencies</h2> -<p>This defines an array of package names that will be bundled when publishing -the package.</p> -<p>In cases where you need to preserve npm packages locally or have them -available through a single file download, you can bundle the packages in a -tarball file by specifying the package names in the <code>bundledDependencies</code> -array and executing <code>npm pack</code>.</p> -<p>For example:</p> -<p>If we define a package.json like this:</p> -<pre><code>{ - "name": "awesome-web-framework", - "version": "1.0.0", - "bundledDependencies": [ - "renderized", "super-streams" - ] -}</code></pre><p>we can obtain <code>awesome-web-framework-1.0.0.tgz</code> file by running <code>npm pack</code>. -This file contains the dependencies <code>renderized</code> and <code>super-streams</code> which -can be installed in a new project by executing <code>npm install -awesome-web-framework-1.0.0.tgz</code>.</p> -<p>If this is spelled <code>"bundleDependencies"</code>, then that is also honored.</p> -<h2 id="optionaldependencies">optionalDependencies</h2> -<p>If a dependency can be used, but you would like npm to proceed if it cannot be -found or fails to install, then you may put it in the <code>optionalDependencies</code> -object. This is a map of package name to version or url, just like the -<code>dependencies</code> object. The difference is that build failures do not cause -installation to fail.</p> -<p>It is still your program's responsibility to handle the lack of the -dependency. For example, something like this:</p> -<pre><code>try { - var foo = require('foo') - var fooVersion = require('foo/package.json').version -} catch (er) { - foo = null -} -if ( notGoodFooVersion(fooVersion) ) { - foo = null -} - -// .. then later in your program .. - -if (foo) { - foo.doFooThings() -}</code></pre><p>Entries in <code>optionalDependencies</code> will override entries of the same name in -<code>dependencies</code>, so it's usually best to only put in one place.</p> -<h2 id="engines">engines</h2> -<p>You can specify the version of node that your stuff works on:</p> -<pre><code>{ "engines" : { "node" : ">=0.10.3 <0.12" } }</code></pre><p>And, like with dependencies, if you don't specify the version (or if you -specify "*" as the version), then any version of node will do.</p> -<p>If you specify an "engines" field, then npm will require that "node" be -somewhere on that list. If "engines" is omitted, then npm will just assume -that it works on node.</p> -<p>You can also use the "engines" field to specify which versions of npm -are capable of properly installing your program. For example:</p> -<pre><code>{ "engines" : { "npm" : "~1.0.20" } }</code></pre><p>Unless the user has set the <code>engine-strict</code> config flag, this -field is advisory only and will only produce warnings when your package is installed as a dependency.</p> -<h2 id="enginestrict">engineStrict</h2> -<p><strong>This feature was removed in npm 3.0.0</strong></p> -<p>Prior to npm 3.0.0, this feature was used to treat this package as if the -user had set <code>engine-strict</code>. It is no longer used.</p> -<h2 id="os">os</h2> -<p>You can specify which operating systems your -module will run on:</p> -<pre><code>"os" : [ "darwin", "linux" ]</code></pre><p>You can also blacklist instead of whitelist operating systems, -just prepend the blacklisted os with a '!':</p> -<pre><code>"os" : [ "!win32" ]</code></pre><p>The host operating system is determined by <code>process.platform</code></p> -<p>It is allowed to both blacklist, and whitelist, although there isn't any -good reason to do this.</p> -<h2 id="cpu">cpu</h2> -<p>If your code only runs on certain cpu architectures, -you can specify which ones.</p> -<pre><code>"cpu" : [ "x64", "ia32" ]</code></pre><p>Like the <code>os</code> option, you can also blacklist architectures:</p> -<pre><code>"cpu" : [ "!arm", "!mips" ]</code></pre><p>The host architecture is determined by <code>process.arch</code></p> -<h2 id="preferglobal">preferGlobal</h2> -<p><strong>DEPRECATED</strong></p> -<p>This option used to trigger an npm warning, but it will no longer warn. It is -purely there for informational purposes. It is now recommended that you install -any binaries as local devDependencies wherever possible.</p> -<h2 id="private">private</h2> -<p>If you set <code>"private": true</code> in your package.json, then npm will refuse -to publish it.</p> -<p>This is a way to prevent accidental publication of private repositories. If -you would like to ensure that a given package is only ever published to a -specific registry (for example, an internal registry), then use the -<code>publishConfig</code> dictionary described below to override the <code>registry</code> config -param at publish-time.</p> -<h2 id="publishconfig">publishConfig</h2> -<p>This is a set of config values that will be used at publish-time. It's -especially handy if you want to set the tag, registry or access, so that -you can ensure that a given package is not tagged with "latest", published -to the global public registry or that a scoped module is private by default.</p> -<p>Any config values can be overridden, but only "tag", "registry" and "access" -probably matter for the purposes of publishing.</p> -<p>See <code><a href="../misc/npm-config.html">npm-config(7)</a></code> to see the list of config options that can be -overridden.</p> -<h2 id="default-values">DEFAULT VALUES</h2> -<p>npm will default some values based on package contents.</p> -<ul> -<li><p><code>"scripts": {"start": "node server.js"}</code></p> -<p>If there is a <code>server.js</code> file in the root of your package, then npm -will default the <code>start</code> command to <code>node server.js</code>.</p> -</li> -<li><p><code>"scripts":{"install": "node-gyp rebuild"}</code></p> -<p>If there is a <code>binding.gyp</code> file in the root of your package and you have not defined an <code>install</code> or <code>preinstall</code> script, npm will -default the <code>install</code> command to compile using node-gyp.</p> -</li> -<li><p><code>"contributors": [...]</code></p> -<p>If there is an <code>AUTHORS</code> file in the root of your package, npm will -treat each line as a <code>Name <email> (url)</code> format, where email and url -are optional. Lines which start with a <code>#</code> or are blank, will be -ignored.</p> -</li> -</ul> -<h2 id="see-also">SEE ALSO</h2> -<ul> -<li><a href="../misc/semver.html">semver(7)</a></li> -<li><a href="../cli/npm-init.html">npm-init(1)</a></li> -<li><a href="../cli/npm-version.html">npm-version(1)</a></li> -<li><a href="../cli/npm-config.html">npm-config(1)</a></li> -<li><a href="../misc/npm-config.html">npm-config(7)</a></li> -<li><a href="../cli/npm-help.html">npm-help(1)</a></li> -<li><a href="../cli/npm-install.html">npm-install(1)</a></li> -<li><a href="../cli/npm-publish.html">npm-publish(1)</a></li> -<li><a href="../cli/npm-uninstall.html">npm-uninstall(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.json — npm@6.7.0</p> - |