Node.js v11.13.0

8 files changed, 2875 insertions, 0 deletions

diff --git a/deps/node/deps/npm/man/man5/npm-folders.5 b/deps/node/deps/npm/man/man5/npm-folders.5
new file mode 100644
index 00000000..0fa03d97
--- /dev/null
+++ b/deps/node/deps/npm/man/man5/npm-folders.5
@@ -0,0 +1,226 @@
+.TH "NPM\-FOLDERS" "5" "January 2019" "" ""
+.SH "NAME"
+\fBnpm-folders\fR \- Folder Structures Used by npm
+.SH DESCRIPTION
+.P
+npm puts various things on your computer\.  That's its job\.
+.P
+This document will tell you what it puts where\.
+.SS tl;dr
+.RS 0
+.IP \(bu 2
+Local install (default): puts stuff in \fB\|\./node_modules\fP of the current
+package root\.
+.IP \(bu 2
+Global install (with \fB\-g\fP): puts stuff in /usr/local or wherever node
+is installed\.
+.IP \(bu 2
+Install it \fBlocally\fR if you're going to \fBrequire()\fP it\.
+.IP \(bu 2
+Install it \fBglobally\fR if you're going to run it on the command line\.
+.IP \(bu 2
+If you need both, then install it in both places, or use \fBnpm link\fP\|\.
+
+.RE
+.SS prefix Configuration
+.P
+The \fBprefix\fP config defaults to the location where node is installed\.
+On most systems, this is \fB/usr/local\fP\|\. On Windows, it's \fB%AppData%\\npm\fP\|\.
+On Unix systems, it's one level up, since node is typically installed at
+\fB{prefix}/bin/node\fP rather than \fB{prefix}/node\.exe\fP\|\.
+.P
+When the \fBglobal\fP 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\.
+.SS Node Modules
+.P
+Packages are dropped into the \fBnode_modules\fP folder under the \fBprefix\fP\|\.
+When installing locally, this means that you can
+\fBrequire("packagename")\fP to load its main module, or
+\fBrequire("packagename/lib/path/to/sub/module")\fP to load other modules\.
+.P
+Global installs on Unix systems go to \fB{prefix}/lib/node_modules\fP\|\.
+Global installs on Windows go to \fB{prefix}/node_modules\fP (that is, no
+\fBlib\fP folder\.)
+.P
+Scoped packages are installed the same way, except they are grouped together
+in a sub\-folder of the relevant \fBnode_modules\fP folder with the name of that
+scope prefix by the @ symbol, e\.g\. \fBnpm install @myorg/package\fP would place
+the package in \fB{prefix}/node_modules/@myorg/package\fP\|\. See npm help 7 \fBscope\fP for
+more details\.
+.P
+If you wish to \fBrequire()\fP a package, then install it locally\.
+.SS Executables
+.P
+When in global mode, executables are linked into \fB{prefix}/bin\fP on Unix,
+or directly into \fB{prefix}\fP on Windows\.
+.P
+When in local mode, executables are linked into
+\fB\|\./node_modules/\.bin\fP 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 \fBnpm test\fP\|\.)
+.SS Man Pages
+.P
+When in global mode, man pages are linked into \fB{prefix}/share/man\fP\|\.
+.P
+When in local mode, man pages are not installed\.
+.P
+Man pages are not installed on Windows systems\.
+.SS Cache
+.P
+See npm help \fBnpm\-cache\fP\|\.  Cache files are stored in \fB~/\.npm\fP on Posix, or
+\fB%AppData%/npm\-cache\fP on Windows\.
+.P
+This is controlled by the \fBcache\fP configuration param\.
+.SS Temp Files
+.P
+Temporary files are stored by default in the folder specified by the
+\fBtmp\fP config, which defaults to the TMPDIR, TMP, or TEMP environment
+variables, or \fB/tmp\fP on Unix and \fBc:\\windows\\temp\fP on Windows\.
+.P
+Temp files are given a unique folder under this root for each run of the
+program, and are deleted upon successful exit\.
+.SH More Information
+.P
+When installing locally, npm first tries to find an appropriate
+\fBprefix\fP folder\.  This is so that \fBnpm install foo@1\.2\.3\fP will install
+to the sensible root of your package, even if you happen to have \fBcd\fPed
+into some other folder\.
+.P
+Starting at the $PWD, npm will walk up the folder tree checking for a
+folder that contains either a \fBpackage\.json\fP file, or a \fBnode_modules\fP
+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
+If no package root is found, then the current folder is used\.
+.P
+When you run \fBnpm install foo@1\.2\.3\fP, then the package is loaded into
+the cache, and then unpacked into \fB\|\./node_modules/foo\fP\|\.  Then, any of
+foo's dependencies are similarly unpacked into
+\fB\|\./node_modules/foo/node_modules/\.\.\.\fP\|\.
+.P
+Any bin files are symlinked to \fB\|\./node_modules/\.bin/\fP, so that they may
+be found by npm scripts when necessary\.
+.SS Global Installation
+.P
+If the \fBglobal\fP configuration is set to true, then npm will
+install packages "globally"\.
+.P
+For global installation, packages are installed roughly the same way,
+but using the folders described above\.
+.SS Cycles, Conflicts, and Folder Parsimony
+.P
+Cycles are handled using the property of node's module system that it
+walks up the directories looking for \fBnode_modules\fP folders\.  So, at every
+stage, if a package is already installed in an ancestor \fBnode_modules\fP
+folder, then it is not installed at the current location\.
+.P
+Consider the case above, where \fBfoo \-> bar \-> baz\fP\|\.  Imagine if, in
+addition to that, baz depended on bar, so you'd have:
+\fBfoo \-> bar \-> baz \-> bar \-> baz \.\.\.\fP\|\.  However, since the folder
+structure is: \fBfoo/node_modules/bar/node_modules/baz\fP, there's no need to
+put another copy of bar into \fB\|\.\.\./baz/node_modules\fP, since when it calls
+require("bar"), it will get the copy that is installed in
+\fBfoo/node_modules/bar\fP\|\.
+.P
+This shortcut is only used if the exact same
+version would be installed in multiple nested \fBnode_modules\fP folders\.  It
+is still possible to have \fBa/node_modules/b/node_modules/a\fP 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
+Another optimization can be made by installing dependencies at the
+highest level possible, below the localized "target" folder\.
+.SS Example
+.P
+Consider this dependency graph:
+.P
+.RS 2
+.nf
+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
+.fi
+.RE
+.P
+In this case, we might expect a folder structure like this:
+.P
+.RS 2
+.nf
+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]
+.fi
+.RE
+.P
+Since foo depends directly on \fBand\fP\fB, those are
+installed in foo's\fPnode_modules` folder\.
+.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 `,
+it does not install another copy under [B]\.
+.P
+Bar [B] also has dependencies on baz and asdf, so those are installed in
+bar's \fBnode_modules\fP folder\.  Because it depends on \fB, it cannot
+re\-use the\fP\fBinstalled in the parent\fPnode_modules` folder [D],
+and must install its own copy [C]\.
+.P
+Underneath bar, the \fBbaz \-> quux \-> bar\fP 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
+Underneath \fBfoo \-> baz\fP [D], quux's [E] folder tree is empty, because its
+dependency on bar is satisfied by the parent folder copy installed at [B]\.
+.P
+For a graphical breakdown of what is installed where, use \fBnpm ls\fP\|\.
+.SS Publishing
+.P
+Upon publishing, npm will look in the \fBnode_modules\fP folder\.  If any of
+the items there are not in the \fBbundledDependencies\fP array, then they will
+not be included in the package tarball\.
+.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 npm help 5 \fBpackage\.json\fP for more information\.
+.SH SEE ALSO
+.RS 0
+.IP \(bu 2
+npm help 5 package\.json
+.IP \(bu 2
+npm help install
+.IP \(bu 2
+npm help pack
+.IP \(bu 2
+npm help cache
+.IP \(bu 2
+npm help config
+.IP \(bu 2
+npm help 5 npmrc
+.IP \(bu 2
+npm help 7 config
+.IP \(bu 2
+npm help publish
+
+.RE
+
diff --git a/deps/node/deps/npm/man/man5/npm-global.5 b/deps/node/deps/npm/man/man5/npm-global.5
new file mode 100644
index 00000000..0fa03d97
--- /dev/null
+++ b/deps/node/deps/npm/man/man5/npm-global.5
@@ -0,0 +1,226 @@
+.TH "NPM\-FOLDERS" "5" "January 2019" "" ""
+.SH "NAME"
+\fBnpm-folders\fR \- Folder Structures Used by npm
+.SH DESCRIPTION
+.P
+npm puts various things on your computer\.  That's its job\.
+.P
+This document will tell you what it puts where\.
+.SS tl;dr
+.RS 0
+.IP \(bu 2
+Local install (default): puts stuff in \fB\|\./node_modules\fP of the current
+package root\.
+.IP \(bu 2
+Global install (with \fB\-g\fP): puts stuff in /usr/local or wherever node
+is installed\.
+.IP \(bu 2
+Install it \fBlocally\fR if you're going to \fBrequire()\fP it\.
+.IP \(bu 2
+Install it \fBglobally\fR if you're going to run it on the command line\.
+.IP \(bu 2
+If you need both, then install it in both places, or use \fBnpm link\fP\|\.
+
+.RE
+.SS prefix Configuration
+.P
+The \fBprefix\fP config defaults to the location where node is installed\.
+On most systems, this is \fB/usr/local\fP\|\. On Windows, it's \fB%AppData%\\npm\fP\|\.
+On Unix systems, it's one level up, since node is typically installed at
+\fB{prefix}/bin/node\fP rather than \fB{prefix}/node\.exe\fP\|\.
+.P
+When the \fBglobal\fP 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\.
+.SS Node Modules
+.P
+Packages are dropped into the \fBnode_modules\fP folder under the \fBprefix\fP\|\.
+When installing locally, this means that you can
+\fBrequire("packagename")\fP to load its main module, or
+\fBrequire("packagename/lib/path/to/sub/module")\fP to load other modules\.
+.P
+Global installs on Unix systems go to \fB{prefix}/lib/node_modules\fP\|\.
+Global installs on Windows go to \fB{prefix}/node_modules\fP (that is, no
+\fBlib\fP folder\.)
+.P
+Scoped packages are installed the same way, except they are grouped together
+in a sub\-folder of the relevant \fBnode_modules\fP folder with the name of that
+scope prefix by the @ symbol, e\.g\. \fBnpm install @myorg/package\fP would place
+the package in \fB{prefix}/node_modules/@myorg/package\fP\|\. See npm help 7 \fBscope\fP for
+more details\.
+.P
+If you wish to \fBrequire()\fP a package, then install it locally\.
+.SS Executables
+.P
+When in global mode, executables are linked into \fB{prefix}/bin\fP on Unix,
+or directly into \fB{prefix}\fP on Windows\.
+.P
+When in local mode, executables are linked into
+\fB\|\./node_modules/\.bin\fP 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 \fBnpm test\fP\|\.)
+.SS Man Pages
+.P
+When in global mode, man pages are linked into \fB{prefix}/share/man\fP\|\.
+.P
+When in local mode, man pages are not installed\.
+.P
+Man pages are not installed on Windows systems\.
+.SS Cache
+.P
+See npm help \fBnpm\-cache\fP\|\.  Cache files are stored in \fB~/\.npm\fP on Posix, or
+\fB%AppData%/npm\-cache\fP on Windows\.
+.P
+This is controlled by the \fBcache\fP configuration param\.
+.SS Temp Files
+.P
+Temporary files are stored by default in the folder specified by the
+\fBtmp\fP config, which defaults to the TMPDIR, TMP, or TEMP environment
+variables, or \fB/tmp\fP on Unix and \fBc:\\windows\\temp\fP on Windows\.
+.P
+Temp files are given a unique folder under this root for each run of the
+program, and are deleted upon successful exit\.
+.SH More Information
+.P
+When installing locally, npm first tries to find an appropriate
+\fBprefix\fP folder\.  This is so that \fBnpm install foo@1\.2\.3\fP will install
+to the sensible root of your package, even if you happen to have \fBcd\fPed
+into some other folder\.
+.P
+Starting at the $PWD, npm will walk up the folder tree checking for a
+folder that contains either a \fBpackage\.json\fP file, or a \fBnode_modules\fP
+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
+If no package root is found, then the current folder is used\.
+.P
+When you run \fBnpm install foo@1\.2\.3\fP, then the package is loaded into
+the cache, and then unpacked into \fB\|\./node_modules/foo\fP\|\.  Then, any of
+foo's dependencies are similarly unpacked into
+\fB\|\./node_modules/foo/node_modules/\.\.\.\fP\|\.
+.P
+Any bin files are symlinked to \fB\|\./node_modules/\.bin/\fP, so that they may
+be found by npm scripts when necessary\.
+.SS Global Installation
+.P
+If the \fBglobal\fP configuration is set to true, then npm will
+install packages "globally"\.
+.P
+For global installation, packages are installed roughly the same way,
+but using the folders described above\.
+.SS Cycles, Conflicts, and Folder Parsimony
+.P
+Cycles are handled using the property of node's module system that it
+walks up the directories looking for \fBnode_modules\fP folders\.  So, at every
+stage, if a package is already installed in an ancestor \fBnode_modules\fP
+folder, then it is not installed at the current location\.
+.P
+Consider the case above, where \fBfoo \-> bar \-> baz\fP\|\.  Imagine if, in
+addition to that, baz depended on bar, so you'd have:
+\fBfoo \-> bar \-> baz \-> bar \-> baz \.\.\.\fP\|\.  However, since the folder
+structure is: \fBfoo/node_modules/bar/node_modules/baz\fP, there's no need to
+put another copy of bar into \fB\|\.\.\./baz/node_modules\fP, since when it calls
+require("bar"), it will get the copy that is installed in
+\fBfoo/node_modules/bar\fP\|\.
+.P
+This shortcut is only used if the exact same
+version would be installed in multiple nested \fBnode_modules\fP folders\.  It
+is still possible to have \fBa/node_modules/b/node_modules/a\fP 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
+Another optimization can be made by installing dependencies at the
+highest level possible, below the localized "target" folder\.
+.SS Example
+.P
+Consider this dependency graph:
+.P
+.RS 2
+.nf
+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
+.fi
+.RE
+.P
+In this case, we might expect a folder structure like this:
+.P
+.RS 2
+.nf
+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]
+.fi
+.RE
+.P
+Since foo depends directly on \fBand\fP\fB, those are
+installed in foo's\fPnode_modules` folder\.
+.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 `,
+it does not install another copy under [B]\.
+.P
+Bar [B] also has dependencies on baz and asdf, so those are installed in
+bar's \fBnode_modules\fP folder\.  Because it depends on \fB, it cannot
+re\-use the\fP\fBinstalled in the parent\fPnode_modules` folder [D],
+and must install its own copy [C]\.
+.P
+Underneath bar, the \fBbaz \-> quux \-> bar\fP 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
+Underneath \fBfoo \-> baz\fP [D], quux's [E] folder tree is empty, because its
+dependency on bar is satisfied by the parent folder copy installed at [B]\.
+.P
+For a graphical breakdown of what is installed where, use \fBnpm ls\fP\|\.
+.SS Publishing
+.P
+Upon publishing, npm will look in the \fBnode_modules\fP folder\.  If any of
+the items there are not in the \fBbundledDependencies\fP array, then they will
+not be included in the package tarball\.
+.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 npm help 5 \fBpackage\.json\fP for more information\.
+.SH SEE ALSO
+.RS 0
+.IP \(bu 2
+npm help 5 package\.json
+.IP \(bu 2
+npm help install
+.IP \(bu 2
+npm help pack
+.IP \(bu 2
+npm help cache
+.IP \(bu 2
+npm help config
+.IP \(bu 2
+npm help 5 npmrc
+.IP \(bu 2
+npm help 7 config
+.IP \(bu 2
+npm help publish
+
+.RE
+
diff --git a/deps/node/deps/npm/man/man5/npm-json.5 b/deps/node/deps/npm/man/man5/npm-json.5
new file mode 100644
index 00000000..dd20f7cb
--- /dev/null
+++ b/deps/node/deps/npm/man/man5/npm-json.5
@@ -0,0 +1,966 @@
+.TH "PACKAGE\.JSON" "5" "January 2019" "" ""
+.SH "NAME"
+\fBpackage.json\fR \- Specifics of npm's package\.json handling
+.SH DESCRIPTION
+.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
+A lot of the behavior described in this document is affected by the config
+settings described in npm help 7 \fBnpm\-config\fP\|\.
+.SH name
+.P
+If you plan to publish your package, the \fImost\fR 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
+The name is what your thing is called\.
+.P
+Some rules:
+.RS 0
+.IP \(bu 2
+The name must be less than or equal to 214 characters\. This includes the scope for
+scoped packages\.
+.IP \(bu 2
+The name can't start with a dot or an underscore\.
+.IP \(bu 2
+New packages must not have uppercase letters in the name\.
+.IP \(bu 2
+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\.
+
+.RE
+.P
+Some tips:
+.RS 0
+.IP \(bu 2
+Don't use the same name as a core Node module\.
+.IP \(bu 2
+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\.)
+.IP \(bu 2
+The name will probably be passed as an argument to require(), so it should
+be something short, but also reasonably descriptive\.
+.IP \(bu 2
+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\. https://www\.npmjs\.com/
+
+.RE
+.P
+A name can be optionally prefixed by a scope, e\.g\. \fB@myorg/mypackage\fP\|\. See
+npm help 7 \fBnpm\-scope\fP for more detail\.
+.SH version
+.P
+If you plan to publish your package, the \fImost\fR 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
+Version must be parseable by
+node\-semver \fIhttps://github\.com/isaacs/node\-semver\fR, which is bundled
+with npm as a dependency\.  (\fBnpm install semver\fP to use it yourself\.)
+.P
+More on version numbers and ranges at npm help 7 semver\.
+.SH description
+.P
+Put a description in it\.  It's a string\.  This helps people discover your
+package, as it's listed in \fBnpm search\fP\|\.
+.SH keywords
+.P
+Put keywords in it\.  It's an array of strings\.  This helps people
+discover your package as it's listed in \fBnpm search\fP\|\.
+.SH homepage
+.P
+The url to the project homepage\.
+.P
+Example:
+.P
+.RS 2
+.nf
+"homepage": "https://github\.com/owner/project#readme"
+.fi
+.RE
+.SH bugs
+.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
+It should look like this:
+.P
+.RS 2
+.nf
+{ "url" : "https://github\.com/owner/project/issues"
+, "email" : "project@hostname\.com"
+}
+.fi
+.RE
+.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
+If a url is provided, it will be used by the \fBnpm bugs\fP command\.
+.SH license
+.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
+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
+.RS 2
+.nf
+{ "license" : "BSD\-3\-Clause" }
+.fi
+.RE
+.P
+You can check the full list of SPDX license IDs \fIhttps://spdx\.org/licenses/\fR\|\.
+Ideally you should pick one that is
+OSI \fIhttps://opensource\.org/licenses/alphabetical\fR approved\.
+.P
+If your package is licensed under multiple common licenses, use an SPDX license
+expression syntax version 2\.0 string \fIhttps://www\.npmjs\.com/package/spdx\fR, like this:
+.P
+.RS 2
+.nf
+{ "license" : "(ISC OR GPL\-3\.0)" }
+.fi
+.RE
+.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
+.RS 2
+.nf
+{ "license" : "SEE LICENSE IN <filename>" }
+.fi
+.RE
+.P
+Then include a file named \fB<filename>\fP at the top level of the package\.
+.P
+Some old packages used license objects or a "licenses" property containing an
+array of license objects:
+.P
+.RS 2
+.nf
+// 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"
+    }
+  ]
+}
+.fi
+.RE
+.P
+Those styles are now deprecated\. Instead, use SPDX expressions, like this:
+.P
+.RS 2
+.nf
+{ "license": "ISC" }
+
+{ "license": "(MIT OR Apache\-2\.0)" }
+.fi
+.RE
+.P
+Finally, if you do not wish to grant others the right to use a private or
+unpublished package under any terms:
+.P
+.RS 2
+.nf
+{ "license": "UNLICENSED" }
+.fi
+.RE
+.P
+Consider also setting \fB"private": true\fP to prevent accidental publication\.
+.SH people fields: author, contributors
+.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
+.RS 2
+.nf
+{ "name" : "Barney Rubble"
+, "email" : "b@rubble\.com"
+, "url" : "http://barnyrubble\.tumblr\.com/"
+}
+.fi
+.RE
+.P
+Or you can shorten that all into a single string, and npm will parse it for you:
+.P
+.RS 2
+.nf
+"Barney Rubble <b@rubble\.com> (http://barnyrubble\.tumblr\.com/)"
+.fi
+.RE
+.P
+Both email and url are optional either way\.
+.P
+npm also sets a top\-level "maintainers" field with your npm user info\.
+.SH files
+.P
+The optional \fBfiles\fP 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 \fB\|\.gitignore\fP, but
+reversed: including a file, directory, or glob pattern (\fB*\fP, \fB**/*\fP, 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 \fB["*"]\fP, which means it will include all files\.
+.P
+Some special files and directories are also included or excluded regardless of
+whether they exist in the \fBfiles\fP array (see below)\.
+.P
+You can also provide a \fB\|\.npmignore\fP 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 \fB\|\.npmignore\fP file works just like a
+\fB\|\.gitignore\fP\|\. If there is a \fB\|\.gitignore\fP file, and \fB\|\.npmignore\fP is
+missing, \fB\|\.gitignore\fP\|'s contents will be used instead\.
+.P
+Files included with the "package\.json#files" field \fIcannot\fR be excluded
+through \fB\|\.npmignore\fP or \fB\|\.gitignore\fP\|\.
+.P
+Certain files are always included, regardless of settings:
+.RS 0
+.IP \(bu 2
+\fBpackage\.json\fP
+.IP \(bu 2
+\fBREADME\fP
+.IP \(bu 2
+\fBCHANGES\fP / \fBCHANGELOG\fP / \fBHISTORY\fP
+.IP \(bu 2
+\fBLICENSE\fP / \fBLICENCE\fP
+.IP \(bu 2
+\fBNOTICE\fP
+.IP \(bu 2
+The file in the "main" field
+
+.RE
+.P
+\fBREADME\fP, \fBCHANGES\fP, \fBLICENSE\fP & \fBNOTICE\fP can have any case and extension\.
+.P
+Conversely, some files are always ignored:
+.RS 0
+.IP \(bu 2
+\fB\|\.git\fP
+.IP \(bu 2
+\fBCVS\fP
+.IP \(bu 2
+\fB\|\.svn\fP
+.IP \(bu 2
+\fB\|\.hg\fP
+.IP \(bu 2
+\fB\|\.lock\-wscript\fP
+.IP \(bu 2
+\fB\|\.wafpickle\-N\fP
+.IP \(bu 2
+\fB\|\.*\.swp\fP
+.IP \(bu 2
+\fB\|\.DS_Store\fP
+.IP \(bu 2
+\fB\|\._*\fP
+.IP \(bu 2
+\fBnpm\-debug\.log\fP
+.IP \(bu 2
+\fB\|\.npmrc\fP
+.IP \(bu 2
+\fBnode_modules\fP
+.IP \(bu 2
+\fBconfig\.gypi\fP
+.IP \(bu 2
+\fB*\.orig\fP
+.IP \(bu 2
+\fBpackage\-lock\.json\fP (use shrinkwrap instead)
+
+.RE
+.SH main
+.P
+The main field is a module ID that is the primary entry point to your program\.
+That is, if your package is named \fBfoo\fP, and a user installs it, and then does
+\fBrequire("foo")\fP, then your main module's exports object will be returned\.
+.P
+This should be a module ID relative to the root of your package folder\.
+.P
+For most modules, it makes the most sense to have a main script and often not
+much else\.
+.SH browser
+.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\. \fBwindow\fP)
+.SH bin
+.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
+To use this, supply a \fBbin\fP field in your package\.json which is a map of
+command name to local file name\. On install, npm will symlink that file into
+\fBprefix/bin\fP for global installs, or \fB\|\./node_modules/\.bin/\fP for local
+installs\.
+.P
+For example, myapp could have this:
+.P
+.RS 2
+.nf
+{ "bin" : { "myapp" : "\./cli\.js" } }
+.fi
+.RE
+.P
+So, when you install myapp, it'll create a symlink from the \fBcli\.js\fP script to
+\fB/usr/local/bin/myapp\fP\|\.
+.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
+.RS 2
+.nf
+{ "name": "my\-program"
+, "version": "1\.2\.5"
+, "bin": "\./path/to/program" }
+.fi
+.RE
+.P
+would be the same as this:
+.P
+.RS 2
+.nf
+{ "name": "my\-program"
+, "version": "1\.2\.5"
+, "bin" : { "my\-program" : "\./path/to/program" } }
+.fi
+.RE
+.P
+Please make sure that your file(s) referenced in \fBbin\fP starts with
+\fB#!/usr/bin/env node\fP, otherwise the scripts are started without the node
+executable!
+.SH man
+.P
+Specify either a single file or an array of filenames to put in place for the
+\fBman\fP program to find\.
+.P
+If only a single file is provided, then it's installed such that it is the
+result from \fBman <pkgname>\fP, regardless of its actual filename\.  For example:
+.P
+.RS 2
+.nf
+{ "name" : "foo"
+, "version" : "1\.2\.3"
+, "description" : "A packaged foo fooer for fooing foos"
+, "main" : "foo\.js"
+, "man" : "\./man/doc\.1"
+}
+.fi
+.RE
+.P
+would link the \fB\|\./man/doc\.1\fP file in such that it is the target for \fBman foo\fP
+.P
+If the filename doesn't start with the package name, then it's prefixed\.
+So, this:
+.P
+.RS 2
+.nf
+{ "name" : "foo"
+, "version" : "1\.2\.3"
+, "description" : "A packaged foo fooer for fooing foos"
+, "main" : "foo\.js"
+, "man" : [ "\./man/foo\.1", "\./man/bar\.1" ]
+}
+.fi
+.RE
+.P
+will create files to do \fBman foo\fP and \fBman foo\-bar\fP\|\.
+.P
+Man files must end with a number, and optionally a \fB\|\.gz\fP suffix if they are
+compressed\.  The number dictates which man section the file is installed into\.
+.P
+.RS 2
+.nf
+{ "name" : "foo"
+, "version" : "1\.2\.3"
+, "description" : "A packaged foo fooer for fooing foos"
+, "main" : "foo\.js"
+, "man" : [ "\./man/foo\.1", "\./man/foo\.2" ]
+}
+.fi
+.RE
+.P
+will create entries for \fBman foo\fP and \fBman 2 foo\fP
+.SH directories
+.P
+The CommonJS Packages \fIhttp://wiki\.commonjs\.org/wiki/Packages/1\.0\fR spec details a
+few ways that you can indicate the structure of your package using a \fBdirectories\fP
+object\. If you look at npm's package\.json \fIhttps://registry\.npmjs\.org/npm/latest\fR,
+you'll see that it has directories for doc, lib, and man\.
+.P
+In the future, this information may be used in other creative ways\.
+.SS directories\.lib
+.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\.
+.SS directories\.bin
+.P
+If you specify a \fBbin\fP directory in \fBdirectories\.bin\fP, all the files in
+that folder will be added\.
+.P
+Because of the way the \fBbin\fP directive works, specifying both a
+\fBbin\fP path and setting \fBdirectories\.bin\fP is an error\. If you want to
+specify individual files, use \fBbin\fP, and for all the files in an
+existing \fBbin\fP directory, use \fBdirectories\.bin\fP\|\.
+.SS directories\.man
+.P
+A folder that is full of man pages\.  Sugar to generate a "man" array by
+walking the folder\.
+.SS directories\.doc
+.P
+Put markdown files in here\.  Eventually, these will be displayed nicely,
+maybe, someday\.
+.SS directories\.example
+.P
+Put example scripts in here\.  Someday, it might be exposed in some clever way\.
+.SS directories\.test
+.P
+Put your tests in here\. It is currently not exposed, but it might be in the
+future\.
+.SH repository
+.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 \fBnpm docs\fP
+command will be able to find you\.
+.P
+Do it like this:
+.P
+.RS 2
+.nf
+"repository": {
+  "type" : "git",
+  "url" : "https://github\.com/npm/cli\.git"
+}
+
+"repository": {
+  "type" : "svn",
+  "url" : "https://v8\.googlecode\.com/svn/trunk/"
+}
+.fi
+.RE
+.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
+For GitHub, GitHub gist, Bitbucket, or GitLab repositories you can use the same
+shortcut syntax you use for \fBnpm install\fP:
+.P
+.RS 2
+.nf
+"repository": "npm/npm"
+
+"repository": "github:user/repo"
+
+"repository": "gist:11081aaa281"
+
+"repository": "bitbucket:user/repo"
+
+"repository": "gitlab:user/repo"
+.fi
+.RE
+.SH scripts
+.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
+See npm help 7 \fBnpm\-scripts\fP to find out more about writing package scripts\.
+.SH config
+.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
+.RS 2
+.nf
+{ "name" : "foo"
+, "config" : { "port" : "8080" } }
+.fi
+.RE
+.P
+and then had a "start" command that then referenced the
+\fBnpm_package_config_port\fP environment variable, then the user could
+override that by doing \fBnpm config set foo:port 8001\fP\|\.
+.P
+See npm help 7 \fBnpm\-config\fP and npm help 7 \fBnpm\-scripts\fP for more on package
+configs\.
+.SH dependencies
+.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
+\fBPlease do not put test harnesses or transpilers in your
+\fBdependencies\fP object\.\fR  See \fBdevDependencies\fP, below\.
+.P
+See npm help 7 semver for more details about specifying version ranges\.
+.RS 0
+.IP \(bu 2
+\fBversion\fP Must match \fBversion\fP exactly
+.IP \(bu 2
+\fB>version\fP Must be greater than \fBversion\fP
+.IP \(bu 2
+\fB>=version\fP etc
+.IP \(bu 2
+\fB<version\fP
+.IP \(bu 2
+\fB<=version\fP
+.IP \(bu 2
+\fB~version\fP "Approximately equivalent to version"  See npm help 7 semver
+.IP \(bu 2
+\fB^version\fP "Compatible with version"  See npm help 7 semver
+.IP \(bu 2
+\fB1\.2\.x\fP 1\.2\.0, 1\.2\.1, etc\., but not 1\.3\.0
+.IP \(bu 2
+\fBhttp://\.\.\.\fP See 'URLs as Dependencies' below
+.IP \(bu 2
+\fB*\fP Matches any version
+.IP \(bu 2
+\fB""\fP (just an empty string) Same as \fB*\fP
+.IP \(bu 2
+\fBversion1 \- version2\fP Same as \fB>=version1 <=version2\fP\|\.
+.IP \(bu 2
+\fBrange1 || range2\fP Passes if either range1 or range2 are satisfied\.
+.IP \(bu 2
+\fBgit\.\.\.\fP See 'Git URLs as Dependencies' below
+.IP \(bu 2
+\fBuser/repo\fP See 'GitHub URLs' below
+.IP \(bu 2
+\fBtag\fP A specific version tagged and published as \fBtag\fP  See npm help \fBnpm\-dist\-tag\fP
+.IP \(bu 2
+\fBpath/path/path\fP See Local Paths \fI#local\-paths\fR below
+
+.RE
+.P
+For example, these are all valid:
+.P
+.RS 2
+.nf
+{ "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"
+  }
+}
+.fi
+.RE
+.SS URLs as Dependencies
+.P
+You may specify a tarball URL in place of a version range\.
+.P
+This tarball will be downloaded and installed locally to your package at
+install time\.
+.SS Git URLs as Dependencies
+.P
+Git urls are of the form:
+.P
+.RS 2
+.nf
+<protocol>://[<user>[:<password>]@]<hostname>[:<port>][:][/]<path>[#<commit\-ish> | #semver:<semver>]
+.fi
+.RE
+.P
+\fB<protocol>\fP is one of \fBgit\fP, \fBgit+ssh\fP, \fBgit+http\fP, \fBgit+https\fP, or
+\fBgit+file\fP\|\.
+.P
+If \fB#<commit\-ish>\fP is provided, it will be used to clone exactly that
+commit\. If the commit\-ish has the format \fB#semver:<semver>\fP, \fB<semver>\fP 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 \fB#<commit\-ish>\fP or \fB#semver:<semver>\fP is
+specified, then \fBmaster\fP is used\.
+.P
+Examples:
+.P
+.RS 2
+.nf
+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
+.fi
+.RE
+.SS GitHub URLs
+.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 \fBcommit\-ish\fP suffix can be
+included\.  For example:
+.P
+.RS 2
+.nf
+{
+  "name": "foo",
+  "version": "0\.0\.0",
+  "dependencies": {
+    "express": "expressjs/express",
+    "mocha": "mochajs/mocha#4727d357ea",
+    "module": "user/repo#feature\\/branch"
+  }
+}
+.fi
+.RE
+.SS Local Paths
+.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 \fBnpm install \-S\fP or
+\fBnpm install \-\-save\fP, using any of these forms:
+.P
+.RS 2
+.nf
+\|\.\./foo/bar
+~/foo/bar
+\|\./foo/bar
+/foo/bar
+.fi
+.RE
+.P
+in which case they will be normalized to a relative path and added to your
+\fBpackage\.json\fP\|\. For example:
+.P
+.RS 2
+.nf
+{
+  "name": "baz",
+  "dependencies": {
+    "bar": "file:\.\./foo/bar"
+  }
+}
+.fi
+.RE
+.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\.
+.SH devDependencies
+.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
+In this case, it's best to map these additional items in a \fBdevDependencies\fP
+object\.
+.P
+These things will be installed when doing \fBnpm link\fP or \fBnpm install\fP
+from the root of a package, and can be managed like any other npm
+configuration param\.  See npm help 7 \fBnpm\-config\fP for more on the topic\.
+.P
+For build steps that are not platform\-specific, such as compiling
+CoffeeScript or other languages to JavaScript, use the \fBprepare\fP
+script to do this, and make the required package a devDependency\.
+.P
+For example:
+.P
+.RS 2
+.nf
+{ "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"
+}
+.fi
+.RE
+.P
+The \fBprepare\fP 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 \fBnpm install\fP), it'll
+run this script as well, so that you can test it easily\.
+.SH peerDependencies
+.P
+In some cases, you want to express the compatibility of your package with a
+host tool or library, while not necessarily doing a \fBrequire\fP of this host\.
+This is usually referred to as a \fIplugin\fR\|\. Notably, your module may be exposing
+a specific interface, expected and specified by the host documentation\.
+.P
+For example:
+.P
+.RS 2
+.nf
+{
+  "name": "tea\-latte",
+  "version": "1\.3\.5",
+  "peerDependencies": {
+    "tea": "2\.x"
+  }
+}
+.fi
+.RE
+.P
+This ensures your package \fBtea\-latte\fP can be installed \fIalong\fR with the second
+major version of the host package \fBtea\fP only\. \fBnpm install tea\-latte\fP could
+possibly yield the following dependency graph:
+.P
+.RS 2
+.nf
+├── tea\-latte@1\.3\.5
+└── tea@2\.2\.0
+.fi
+.RE
+.P
+\fBNOTE: npm versions 1 and 2 will automatically install \fBpeerDependencies\fP 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\.\fR 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
+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
+Assuming the host complies with semver \fIhttps://semver\.org/\fR, 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 \fB"^1\.0"\fP or \fB"1\.x"\fP to express
+this\. If you depend on features introduced in 1\.5\.2, use \fB">= 1\.5\.2 < 2"\fP\|\.
+.SH bundledDependencies
+.P
+This defines an array of package names that will be bundled when publishing
+the package\.
+.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 \fBbundledDependencies\fP
+array and executing \fBnpm pack\fP\|\.
+.P
+For example:
+.P
+If we define a package\.json like this:
+.P
+.RS 2
+.nf
+{
+  "name": "awesome\-web\-framework",
+  "version": "1\.0\.0",
+  "bundledDependencies": [
+    "renderized", "super\-streams"
+  ]
+}
+.fi
+.RE
+.P
+we can obtain \fBawesome\-web\-framework\-1\.0\.0\.tgz\fP file by running \fBnpm pack\fP\|\.
+This file contains the dependencies \fBrenderized\fP and \fBsuper\-streams\fP which
+can be installed in a new project by executing \fBnpm install
+awesome\-web\-framework\-1\.0\.0\.tgz\fP\|\.
+.P
+If this is spelled \fB"bundleDependencies"\fP, then that is also honored\.
+.SH optionalDependencies
+.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 \fBoptionalDependencies\fP
+object\.  This is a map of package name to version or url, just like the
+\fBdependencies\fP object\.  The difference is that build failures do not cause
+installation to fail\.
+.P
+It is still your program's responsibility to handle the lack of the
+dependency\.  For example, something like this:
+.P
+.RS 2
+.nf
+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()
+}
+.fi
+.RE
+.P
+Entries in \fBoptionalDependencies\fP will override entries of the same name in
+\fBdependencies\fP, so it's usually best to only put in one place\.
+.SH engines
+.P
+You can specify the version of node that your stuff works on:
+.P
+.RS 2
+.nf
+{ "engines" : { "node" : ">=0\.10\.3 <0\.12" } }
+.fi
+.RE
+.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
+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
+You can also use the "engines" field to specify which versions of npm
+are capable of properly installing your program\.  For example:
+.P
+.RS 2
+.nf
+{ "engines" : { "npm" : "~1\.0\.20" } }
+.fi
+.RE
+.P
+Unless the user has set the \fBengine\-strict\fP config flag, this
+field is advisory only and will only produce warnings when your package is installed as a dependency\.
+.SH engineStrict
+.P
+\fBThis feature was removed in npm 3\.0\.0\fR
+.P
+Prior to npm 3\.0\.0, this feature was used to treat this package as if the
+user had set \fBengine\-strict\fP\|\. It is no longer used\.
+.SH os
+.P
+You can specify which operating systems your
+module will run on:
+.P
+.RS 2
+.nf
+"os" : [ "darwin", "linux" ]
+.fi
+.RE
+.P
+You can also blacklist instead of whitelist operating systems,
+just prepend the blacklisted os with a '!':
+.P
+.RS 2
+.nf
+"os" : [ "!win32" ]
+.fi
+.RE
+.P
+The host operating system is determined by \fBprocess\.platform\fP
+.P
+It is allowed to both blacklist, and whitelist, although there isn't any
+good reason to do this\.
+.SH cpu
+.P
+If your code only runs on certain cpu architectures,
+you can specify which ones\.
+.P
+.RS 2
+.nf
+"cpu" : [ "x64", "ia32" ]
+.fi
+.RE
+.P
+Like the \fBos\fP option, you can also blacklist architectures:
+.P
+.RS 2
+.nf
+"cpu" : [ "!arm", "!mips" ]
+.fi
+.RE
+.P
+The host architecture is determined by \fBprocess\.arch\fP
+.SH preferGlobal
+.P
+\fBDEPRECATED\fR
+.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\.
+.SH private
+.P
+If you set \fB"private": true\fP in your package\.json, then npm will refuse
+to publish it\.
+.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
+\fBpublishConfig\fP dictionary described below to override the \fBregistry\fP config
+param at publish\-time\.
+.SH publishConfig
+.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
+Any config values can be overridden, but only "tag", "registry" and "access"
+probably matter for the purposes of publishing\.
+.P
+See npm help 7 \fBnpm\-config\fP to see the list of config options that can be
+overridden\.
+.SH DEFAULT VALUES
+.P
+npm will default some values based on package contents\.
+.RS 0
+.IP \(bu 2
+\fB"scripts": {"start": "node server\.js"}\fP
+If there is a \fBserver\.js\fP file in the root of your package, then npm
+will default the \fBstart\fP command to \fBnode server\.js\fP\|\.
+.IP \(bu 2
+\fB"scripts":{"install": "node\-gyp rebuild"}\fP
+If there is a \fBbinding\.gyp\fP file in the root of your package and you have not defined an \fBinstall\fP or \fBpreinstall\fP script, npm will
+default the \fBinstall\fP command to compile using node\-gyp\.
+.IP \(bu 2
+\fB"contributors": [\.\.\.]\fP
+If there is an \fBAUTHORS\fP file in the root of your package, npm will
+treat each line as a \fBName <email> (url)\fP format, where email and url
+are optional\.  Lines which start with a \fB#\fP or are blank, will be
+ignored\.
+
+.RE
+.SH SEE ALSO
+.RS 0
+.IP \(bu 2
+npm help 7 semver
+.IP \(bu 2
+npm help init
+.IP \(bu 2
+npm help version
+.IP \(bu 2
+npm help config
+.IP \(bu 2
+npm help 7 config
+.IP \(bu 2
+npm help help
+.IP \(bu 2
+npm help install
+.IP \(bu 2
+npm help publish
+.IP \(bu 2
+npm help uninstall
+
+.RE
+
diff --git a/deps/node/deps/npm/man/man5/npm-package-locks.5 b/deps/node/deps/npm/man/man5/npm-package-locks.5
new file mode 100644
index 00000000..b3692ceb
--- /dev/null
+++ b/deps/node/deps/npm/man/man5/npm-package-locks.5
@@ -0,0 +1,198 @@
+.TH "NPM\-PACKAGE\-LOCKS" "5" "January 2019" "" ""
+.SH "NAME"
+\fBnpm-package-locks\fR \- An explanation of npm lockfiles
+.SH DESCRIPTION
+.P
+Conceptually, the "input" to npm help install is a npm help 5 package\.json, while its
+"output" is a fully\-formed \fBnode_modules\fP tree: a representation of the
+dependencies you declared\. In an ideal world, npm would work like a pure
+function: the same \fBpackage\.json\fP should produce the exact same \fBnode_modules\fP
+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:
+.RS 0
+.IP \(bu 2
+different versions of npm (or other package managers) may have been used to install a package, each using slightly different installation algorithms\.
+.IP \(bu 2
+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\.
+.IP \(bu 2
+A dependency of one of your dependencies may have published a new version, which will update even if you used pinned dependency specifiers (\fB1\.2\.3\fP instead of \fB^1\.2\.3\fP)
+.IP \(bu 2
+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\.
+
+.RE
+.P
+As an example, consider package A:
+.P
+.RS 2
+.nf
+{
+  "name": "A",
+  "version": "0\.1\.0",
+  "dependencies": {
+    "B": "<0\.1\.0"
+  }
+}
+.fi
+.RE
+.P
+package B:
+.P
+.RS 2
+.nf
+{
+  "name": "B",
+  "version": "0\.0\.1",
+  "dependencies": {
+    "C": "<0\.1\.0"
+  }
+}
+.fi
+.RE
+.P
+and package C:
+.P
+.RS 2
+.nf
+{
+  "name": "C",
+  "version": "0\.0\.1"
+}
+.fi
+.RE
+.P
+If these are the only versions of A, B, and C available in the
+registry, then a normal \fBnpm install A\fP will install:
+.P
+.RS 2
+.nf
+A@0\.1\.0
+`\-\- B@0\.0\.1
+    `\-\- C@0\.0\.1
+.fi
+.RE
+.P
+However, if  is published, then a fresh \fBnpm install A\fP will
+install:
+.P
+.RS 2
+.nf
+A@0\.1\.0
+`\-\- B@0\.0\.2
+    `\-\- C@0\.0\.1
+.fi
+.RE
+.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 \|\. 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
+To prevent this potential issue, npm uses npm help 5 package\-lock\.json or, if present,
+npm help 5 shrinkwrap\.json\. These files are called package locks, or lockfiles\.
+.P
+Whenever you run \fBnpm install\fP, npm generates or updates your package lock,
+which will look something like this:
+.P
+.RS 2
+.nf
+{
+  "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"
+        }
+      }
+    }
+  }
+}
+.fi
+.RE
+.P
+This file describes an \fIexact\fR, and more importantly \fIreproducible\fR
+\fBnode_modules\fP tree\. Once it's present, any future installation will base its
+work off this file, instead of recalculating dependency versions off
+npm help 5 package\.json\.
+.P
+The presence of a package lock changes the installation behavior such that:
+.RS 0
+.IP 1. 3
+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\.
+.IP 2. 3
+The tree is walked and any missing dependencies are installed in the usual
+fashion\.
+
+.RE
+.P
+If \fBpreshrinkwrap\fP, \fBshrinkwrap\fP or \fBpostshrinkwrap\fP are in the \fBscripts\fP
+property of the \fBpackage\.json\fP, they will be executed in order\. \fBpreshrinkwrap\fP
+and \fBshrinkwrap\fP are executed before the shrinkwrap, \fBpostshrinkwrap\fP is
+executed afterwards\. These scripts run for both \fBpackage\-lock\.json\fP and
+\fBnpm\-shrinkwrap\.json\fP\|\. For example to run some postprocessing on the generated
+file:
+.P
+.RS 2
+.nf
+"scripts": {
+  "postshrinkwrap": "json \-I \-e \\"this\.myMetadata = $MY_APP_METADATA\\""
+}
+.fi
+.RE
+.SS Using locked packages
+.P
+Using a locked package is no different than using any package without a package
+lock: any commands that update \fBnode_modules\fP and/or \fBpackage\.json\fP\|'s
+dependencies will automatically sync the existing lockfile\. This includes \fBnpm
+install\fP, \fBnpm rm\fP, \fBnpm update\fP, etc\. To prevent this update from happening,
+you can use the \fB\-\-no\-save\fP option to prevent saving altogether, or
+\fB\-\-no\-shrinkwrap\fP to allow \fBpackage\.json\fP to be updated while leaving
+\fBpackage\-lock\.json\fP or \fBnpm\-shrinkwrap\.json\fP intact\.
+.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 \fBnpm install\fP 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 \fBnode_modules\fP, so you can notice
+if any transitive dependencies were updated, hoisted, etc\.
+.SS Resolving lockfile conflicts
+.P
+Occasionally, two separate npm install will create package locks that cause
+merge conflicts in source control systems\. As of \fB, these conflicts
+can be resolved by manually fixing any\fPpackage\.json\fBconflicts, and then
+running\fPnpm install [\-\-package\-lock\-only]\fBagain\. 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\fP\-\-package\-lock\-only\fBis provided, it will do this without also modifying your
+local\fPnode_modules/`\.
+.P
+To make this process seamless on git, consider installing
+\fBnpm\-merge\-driver\fP \fIhttps://npm\.im/npm\-merge\-driver\fR, which will teach git how
+to do this itself without any user interaction\. In short: \fB$ npx
+npm\-merge\-driver install \-g\fP will let you do this, and even works with
+\fBversions of npm 5, albeit a bit more noisily\. Note that if\fPpackage\.json\fBitself conflicts, you will have to resolve that by hand and run\fPnpm install` manually, even with the merge driver\.
+.SH SEE ALSO
+.RS 0
+.IP \(bu 2
+https://
+.IP \(bu 2
+npm help 5 package\.json
+.IP \(bu 2
+npm help 5 package\-lock\.json
+.IP \(bu 2
+npm help 5 shrinkwrap\.json
+.IP \(bu 2
+npm help shrinkwrap
+
+.RE
diff --git a/deps/node/deps/npm/man/man5/npm-shrinkwrap.json.5 b/deps/node/deps/npm/man/man5/npm-shrinkwrap.json.5
new file mode 100644
index 00000000..c1d4db9a
--- /dev/null
+++ b/deps/node/deps/npm/man/man5/npm-shrinkwrap.json.5
@@ -0,0 +1,32 @@
+.TH "NPM\-SHRINKWRAP\.JSON" "5" "January 2019" "" ""
+.SH "NAME"
+\fBnpm-shrinkwrap.json\fR \- A publishable lockfile
+.SH DESCRIPTION
+.P
+\fBnpm\-shrinkwrap\.json\fP is a file created by npm help shrinkwrap\. It is identical to
+\fBpackage\-lock\.json\fP, with one major caveat: Unlike \fBpackage\-lock\.json\fP,
+\fBnpm\-shrinkwrap\.json\fP may be included when publishing a package\.
+.P
+The recommended use\-case for \fBnpm\-shrinkwrap\.json\fP is applications deployed
+through the publishing process on the registry: for example, daemons and
+command\-line tools intended as global installs or \fBdevDependencies\fP\|\. 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
+Additionally, if both \fBpackage\-lock\.json\fP and \fBnpm\-shrinkwrap\.json\fP are present
+in a package root, \fBpackage\-lock\.json\fP will be ignored in favor of this file\.
+.P
+For full details and description of the \fBnpm\-shrinkwrap\.json\fP file format, refer
+to the manual page for npm help 5 package\-lock\.json\.
+.SH SEE ALSO
+.RS 0
+.IP \(bu 2
+npm help shrinkwrap
+.IP \(bu 2
+npm help 5 package\-lock\.json
+.IP \(bu 2
+npm help 5 package\.json
+.IP \(bu 2
+npm help install
+
+.RE
diff --git a/deps/node/deps/npm/man/man5/npmrc.5 b/deps/node/deps/npm/man/man5/npmrc.5
new file mode 100644
index 00000000..3d6bf7d5
--- /dev/null
+++ b/deps/node/deps/npm/man/man5/npmrc.5
@@ -0,0 +1,109 @@
+.TH "NPMRC" "5" "January 2019" "" ""
+.SH "NAME"
+\fBnpmrc\fR \- The npm config files
+.SH DESCRIPTION
+.P
+npm gets its config settings from the command line, environment
+variables, and \fBnpmrc\fP files\.
+.P
+The \fBnpm config\fP command can be used to update and edit the contents
+of the user and global npmrc files\.
+.P
+For a list of available configuration options, see npm help 7 config\.
+.SH FILES
+.P
+The four relevant files are:
+.RS 0
+.IP \(bu 2
+per\-project config file (/path/to/my/project/\.npmrc)
+.IP \(bu 2
+per\-user config file (~/\.npmrc)
+.IP \(bu 2
+global config file ($PREFIX/etc/npmrc)
+.IP \(bu 2
+npm builtin config file (/path/to/npm/npmrc)
+
+.RE
+.P
+All npm config files are an ini\-formatted list of \fBkey = value\fP
+parameters\.  Environment variables can be replaced using
+\fB${VARIABLE_NAME}\fP\|\. For example:
+.P
+.RS 2
+.nf
+prefix = ${HOME}/\.npm\-packages
+.fi
+.RE
+.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
+Array values are specified by adding "[]" after the key name\. For
+example:
+.P
+.RS 2
+.nf
+key[] = "first value"
+key[] = "second value"
+.fi
+.RE
+.SS Comments
+.P
+Lines in \fB\|\.npmrc\fP files are interpreted as comments when they begin with a \fB;\fP or \fB#\fP character\. \fB\|\.npmrc\fP files are parsed by npm/ini \fIhttps://github\.com/npm/ini\fR, which specifies this comment syntax\.
+.P
+For example:
+.P
+.RS 2
+.nf
+# last modified: 01 Jan 2016
+; Set a new registry for a scoped package
+@myscope:registry=https://mycustomregistry\.example\.org
+.fi
+.RE
+.SS Per\-project config file
+.P
+When working locally in a project, a \fB\|\.npmrc\fP file in the root of the
+project (ie, a sibling of \fBnode_modules\fP and \fBpackage\.json\fP) will set
+config values specific to this project\.
+.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
+Additionally, this file is not read in global mode, such as when running
+\fBnpm install \-g\fP\|\.
+.SS Per\-user config file
+.P
+\fB$HOME/\.npmrc\fP (or the \fBuserconfig\fP param, if set in the environment
+or on the command line)
+.SS Global config file
+.P
+\fB$PREFIX/etc/npmrc\fP (or the \fBglobalconfig\fP param, if set above):
+This file is an ini\-file formatted list of \fBkey = value\fP parameters\.
+Environment variables can be replaced as above\.
+.SS Built\-in config file
+.P
+\fBpath/to/npm/itself/npmrc\fP
+.P
+This is an unchangeable "builtin" configuration file that npm keeps
+consistent across updates\.  Set fields in here using the \fB\|\./configure\fP
+script that comes with npm\.  This is primarily for distribution
+maintainers to override default configs in a standard and consistent
+manner\.
+.SH SEE ALSO
+.RS 0
+.IP \(bu 2
+npm help 5 folders
+.IP \(bu 2
+npm help config
+.IP \(bu 2
+npm help 7 config
+.IP \(bu 2
+npm help 5 package\.json
+.IP \(bu 2
+npm help npm
+
+.RE
+
diff --git a/deps/node/deps/npm/man/man5/package-lock.json.5 b/deps/node/deps/npm/man/man5/package-lock.json.5
new file mode 100644
index 00000000..dcb21542
--- /dev/null
+++ b/deps/node/deps/npm/man/man5/package-lock.json.5
@@ -0,0 +1,152 @@
+.TH "PACKAGE\-LOCK\.JSON" "5" "January 2019" "" ""
+.SH "NAME"
+\fBpackage-lock.json\fR \- A manifestation of the manifest
+.SH DESCRIPTION
+.P
+\fBpackage\-lock\.json\fP is automatically generated for any operations where npm
+modifies either the \fBnode_modules\fP tree, or \fBpackage\.json\fP\|\. It describes the
+exact tree that was generated, such that subsequent installs are able to
+generate identical trees, regardless of intermediate dependency updates\.
+.P
+This file is intended to be committed into source repositories, and serves
+various purposes:
+.RS 0
+.IP \(bu 2
+Describe a single representation of a dependency tree such that teammates, deployments, and continuous integration are guaranteed to install exactly the same dependencies\.
+.IP \(bu 2
+Provide a facility for users to "time\-travel" to previous states of \fBnode_modules\fP without having to commit the directory itself\.
+.IP \(bu 2
+To facilitate greater visibility of tree changes through readable source control diffs\.
+.IP \(bu 2
+And optimize the installation process by allowing npm to skip repeated metadata resolutions for previously\-installed packages\.
+
+.RE
+.P
+One key detail about \fBpackage\-lock\.json\fP is that it cannot be published, and it
+will be ignored if found in any place other than the toplevel package\. It shares
+a format with npm help 5 shrinkwrap\.json, which is essentially the same file, but
+allows publication\. This is not recommended unless deploying a CLI tool or
+otherwise using the publication process for producing production packages\.
+.P
+If both \fBpackage\-lock\.json\fP and \fBnpm\-shrinkwrap\.json\fP are present in the root of
+a package, \fBpackage\-lock\.json\fP will be completely ignored\.
+.SH FILE FORMAT
+.SS name
+.P
+The name of the package this is a package\-lock for\. This must match what's in
+\fBpackage\.json\fP\|\.
+.SS version
+.P
+The version of the package this is a package\-lock for\. This must match what's in
+\fBpackage\.json\fP\|\.
+.SS lockfileVersion
+.P
+An integer version, starting at \fB1\fP with the version number of this document
+whose semantics were used when generating this \fBpackage\-lock\.json\fP\|\.
+.SS packageIntegrity
+.P
+This is a subresource
+integrity \fIhttps://w3c\.github\.io/webappsec/specs/subresourceintegrity/\fR value
+created from the \fBpackage\.json\fP\|\. No preprocessing of the \fBpackage\.json\fP should
+be done\. Subresource integrity strings can be produced by modules like
+\fBssri\fP \fIhttps://www\.npmjs\.com/package/ssri\fR\|\.
+.SS preserveSymlinks
+.P
+Indicates that the install was done with the environment variable
+\fBNODE_PRESERVE_SYMLINKS\fP enabled\. The installer should insist that the value of
+this property match that environment variable\.
+.SS dependencies
+.P
+A mapping of package name to dependency object\.  Dependency objects have the
+following properties:
+.SS version
+.P
+This is a specifier that uniquely identifies this package and should be
+usable in fetching a new copy of it\.
+.RS 0
+.IP \(bu 2
+bundled dependencies: Regardless of source, this is a version number that is purely for informational purposes\.
+.IP \(bu 2
+registry sources: This is a version number\. (eg, \fB1\.2\.3\fP)
+.IP \(bu 2
+git sources: This is a git specifier with resolved committish\. (eg, \fBgit+https://example\.com/foo/bar#115311855adb0789a0466714ed48a1499ffea97e\fP)
+.IP \(bu 2
+http tarball sources: This is the URL of the tarball\. (eg, \fBhttps://example\.com/example\-1\.3\.0\.tgz\fP)
+.IP \(bu 2
+local tarball sources: This is the file URL of the tarball\. (eg \fBfile:///opt/storage/example\-1\.3\.0\.tgz\fP)
+.IP \(bu 2
+local link sources: This is the file URL of the link\. (eg \fBfile:libs/our\-module\fP)
+
+.RE
+.SS integrity
+.P
+This is a Standard Subresource
+Integrity \fIhttps://w3c\.github\.io/webappsec/specs/subresourceintegrity/\fR for this
+resource\.
+.RS 0
+.IP \(bu 2
+For bundled dependencies this is not included, regardless of source\.
+.IP \(bu 2
+For registry sources, this is the \fBintegrity\fP that the registry provided, or if one wasn't provided the SHA1 in \fBshasum\fP\|\.
+.IP \(bu 2
+For git sources this is the specific commit hash we cloned from\.
+.IP \(bu 2
+For remote tarball sources this is an integrity based on a SHA512 of
+the file\.
+.IP \(bu 2
+For local tarball sources: This is an integrity field based on the SHA512 of the file\.
+
+.RE
+.SS resolved
+.RS 0
+.IP \(bu 2
+For bundled dependencies this is not included, regardless of source\.
+.IP \(bu 2
+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\.
+
+.RE
+.SS bundled
+.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\.
+.SS dev
+.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\.
+.SS optional
+.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
+All optional dependencies should be included even if they're uninstallable
+on the current platform\.
+.SS requires
+.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
+\fBdependencies\fP or in a level higher than us\.
+.SS dependencies
+.P
+The dependencies of this dependency, exactly as at the top level\.
+.SH SEE ALSO
+.RS 0
+.IP \(bu 2
+npm help shrinkwrap
+.IP \(bu 2
+npm help 5 shrinkwrap\.json
+.IP \(bu 2
+npm help 5 package\-locks
+.IP \(bu 2
+npm help 5 package\.json
+.IP \(bu 2
+npm help install
+
+.RE
diff --git a/deps/node/deps/npm/man/man5/package.json.5 b/deps/node/deps/npm/man/man5/package.json.5
new file mode 100644
index 00000000..dd20f7cb
--- /dev/null
+++ b/deps/node/deps/npm/man/man5/package.json.5
@@ -0,0 +1,966 @@
+.TH "PACKAGE\.JSON" "5" "January 2019" "" ""
+.SH "NAME"
+\fBpackage.json\fR \- Specifics of npm's package\.json handling
+.SH DESCRIPTION
+.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
+A lot of the behavior described in this document is affected by the config
+settings described in npm help 7 \fBnpm\-config\fP\|\.
+.SH name
+.P
+If you plan to publish your package, the \fImost\fR 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
+The name is what your thing is called\.
+.P
+Some rules:
+.RS 0
+.IP \(bu 2
+The name must be less than or equal to 214 characters\. This includes the scope for
+scoped packages\.
+.IP \(bu 2
+The name can't start with a dot or an underscore\.
+.IP \(bu 2
+New packages must not have uppercase letters in the name\.
+.IP \(bu 2
+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\.
+
+.RE
+.P
+Some tips:
+.RS 0
+.IP \(bu 2
+Don't use the same name as a core Node module\.
+.IP \(bu 2
+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\.)
+.IP \(bu 2
+The name will probably be passed as an argument to require(), so it should
+be something short, but also reasonably descriptive\.
+.IP \(bu 2
+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\. https://www\.npmjs\.com/
+
+.RE
+.P
+A name can be optionally prefixed by a scope, e\.g\. \fB@myorg/mypackage\fP\|\. See
+npm help 7 \fBnpm\-scope\fP for more detail\.
+.SH version
+.P
+If you plan to publish your package, the \fImost\fR 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
+Version must be parseable by
+node\-semver \fIhttps://github\.com/isaacs/node\-semver\fR, which is bundled
+with npm as a dependency\.  (\fBnpm install semver\fP to use it yourself\.)
+.P
+More on version numbers and ranges at npm help 7 semver\.
+.SH description
+.P
+Put a description in it\.  It's a string\.  This helps people discover your
+package, as it's listed in \fBnpm search\fP\|\.
+.SH keywords
+.P
+Put keywords in it\.  It's an array of strings\.  This helps people
+discover your package as it's listed in \fBnpm search\fP\|\.
+.SH homepage
+.P
+The url to the project homepage\.
+.P
+Example:
+.P
+.RS 2
+.nf
+"homepage": "https://github\.com/owner/project#readme"
+.fi
+.RE
+.SH bugs
+.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
+It should look like this:
+.P
+.RS 2
+.nf
+{ "url" : "https://github\.com/owner/project/issues"
+, "email" : "project@hostname\.com"
+}
+.fi
+.RE
+.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
+If a url is provided, it will be used by the \fBnpm bugs\fP command\.
+.SH license
+.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
+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
+.RS 2
+.nf
+{ "license" : "BSD\-3\-Clause" }
+.fi
+.RE
+.P
+You can check the full list of SPDX license IDs \fIhttps://spdx\.org/licenses/\fR\|\.
+Ideally you should pick one that is
+OSI \fIhttps://opensource\.org/licenses/alphabetical\fR approved\.
+.P
+If your package is licensed under multiple common licenses, use an SPDX license
+expression syntax version 2\.0 string \fIhttps://www\.npmjs\.com/package/spdx\fR, like this:
+.P
+.RS 2
+.nf
+{ "license" : "(ISC OR GPL\-3\.0)" }
+.fi
+.RE
+.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
+.RS 2
+.nf
+{ "license" : "SEE LICENSE IN <filename>" }
+.fi
+.RE
+.P
+Then include a file named \fB<filename>\fP at the top level of the package\.
+.P
+Some old packages used license objects or a "licenses" property containing an
+array of license objects:
+.P
+.RS 2
+.nf
+// 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"
+    }
+  ]
+}
+.fi
+.RE
+.P
+Those styles are now deprecated\. Instead, use SPDX expressions, like this:
+.P
+.RS 2
+.nf
+{ "license": "ISC" }
+
+{ "license": "(MIT OR Apache\-2\.0)" }
+.fi
+.RE
+.P
+Finally, if you do not wish to grant others the right to use a private or
+unpublished package under any terms:
+.P
+.RS 2
+.nf
+{ "license": "UNLICENSED" }
+.fi
+.RE
+.P
+Consider also setting \fB"private": true\fP to prevent accidental publication\.
+.SH people fields: author, contributors
+.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
+.RS 2
+.nf
+{ "name" : "Barney Rubble"
+, "email" : "b@rubble\.com"
+, "url" : "http://barnyrubble\.tumblr\.com/"
+}
+.fi
+.RE
+.P
+Or you can shorten that all into a single string, and npm will parse it for you:
+.P
+.RS 2
+.nf
+"Barney Rubble <b@rubble\.com> (http://barnyrubble\.tumblr\.com/)"
+.fi
+.RE
+.P
+Both email and url are optional either way\.
+.P
+npm also sets a top\-level "maintainers" field with your npm user info\.
+.SH files
+.P
+The optional \fBfiles\fP 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 \fB\|\.gitignore\fP, but
+reversed: including a file, directory, or glob pattern (\fB*\fP, \fB**/*\fP, 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 \fB["*"]\fP, which means it will include all files\.
+.P
+Some special files and directories are also included or excluded regardless of
+whether they exist in the \fBfiles\fP array (see below)\.
+.P
+You can also provide a \fB\|\.npmignore\fP 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 \fB\|\.npmignore\fP file works just like a
+\fB\|\.gitignore\fP\|\. If there is a \fB\|\.gitignore\fP file, and \fB\|\.npmignore\fP is
+missing, \fB\|\.gitignore\fP\|'s contents will be used instead\.
+.P
+Files included with the "package\.json#files" field \fIcannot\fR be excluded
+through \fB\|\.npmignore\fP or \fB\|\.gitignore\fP\|\.
+.P
+Certain files are always included, regardless of settings:
+.RS 0
+.IP \(bu 2
+\fBpackage\.json\fP
+.IP \(bu 2
+\fBREADME\fP
+.IP \(bu 2
+\fBCHANGES\fP / \fBCHANGELOG\fP / \fBHISTORY\fP
+.IP \(bu 2
+\fBLICENSE\fP / \fBLICENCE\fP
+.IP \(bu 2
+\fBNOTICE\fP
+.IP \(bu 2
+The file in the "main" field
+
+.RE
+.P
+\fBREADME\fP, \fBCHANGES\fP, \fBLICENSE\fP & \fBNOTICE\fP can have any case and extension\.
+.P
+Conversely, some files are always ignored:
+.RS 0
+.IP \(bu 2
+\fB\|\.git\fP
+.IP \(bu 2
+\fBCVS\fP
+.IP \(bu 2
+\fB\|\.svn\fP
+.IP \(bu 2
+\fB\|\.hg\fP
+.IP \(bu 2
+\fB\|\.lock\-wscript\fP
+.IP \(bu 2
+\fB\|\.wafpickle\-N\fP
+.IP \(bu 2
+\fB\|\.*\.swp\fP
+.IP \(bu 2
+\fB\|\.DS_Store\fP
+.IP \(bu 2
+\fB\|\._*\fP
+.IP \(bu 2
+\fBnpm\-debug\.log\fP
+.IP \(bu 2
+\fB\|\.npmrc\fP
+.IP \(bu 2
+\fBnode_modules\fP
+.IP \(bu 2
+\fBconfig\.gypi\fP
+.IP \(bu 2
+\fB*\.orig\fP
+.IP \(bu 2
+\fBpackage\-lock\.json\fP (use shrinkwrap instead)
+
+.RE
+.SH main
+.P
+The main field is a module ID that is the primary entry point to your program\.
+That is, if your package is named \fBfoo\fP, and a user installs it, and then does
+\fBrequire("foo")\fP, then your main module's exports object will be returned\.
+.P
+This should be a module ID relative to the root of your package folder\.
+.P
+For most modules, it makes the most sense to have a main script and often not
+much else\.
+.SH browser
+.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\. \fBwindow\fP)
+.SH bin
+.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
+To use this, supply a \fBbin\fP field in your package\.json which is a map of
+command name to local file name\. On install, npm will symlink that file into
+\fBprefix/bin\fP for global installs, or \fB\|\./node_modules/\.bin/\fP for local
+installs\.
+.P
+For example, myapp could have this:
+.P
+.RS 2
+.nf
+{ "bin" : { "myapp" : "\./cli\.js" } }
+.fi
+.RE
+.P
+So, when you install myapp, it'll create a symlink from the \fBcli\.js\fP script to
+\fB/usr/local/bin/myapp\fP\|\.
+.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
+.RS 2
+.nf
+{ "name": "my\-program"
+, "version": "1\.2\.5"
+, "bin": "\./path/to/program" }
+.fi
+.RE
+.P
+would be the same as this:
+.P
+.RS 2
+.nf
+{ "name": "my\-program"
+, "version": "1\.2\.5"
+, "bin" : { "my\-program" : "\./path/to/program" } }
+.fi
+.RE
+.P
+Please make sure that your file(s) referenced in \fBbin\fP starts with
+\fB#!/usr/bin/env node\fP, otherwise the scripts are started without the node
+executable!
+.SH man
+.P
+Specify either a single file or an array of filenames to put in place for the
+\fBman\fP program to find\.
+.P
+If only a single file is provided, then it's installed such that it is the
+result from \fBman <pkgname>\fP, regardless of its actual filename\.  For example:
+.P
+.RS 2
+.nf
+{ "name" : "foo"
+, "version" : "1\.2\.3"
+, "description" : "A packaged foo fooer for fooing foos"
+, "main" : "foo\.js"
+, "man" : "\./man/doc\.1"
+}
+.fi
+.RE
+.P
+would link the \fB\|\./man/doc\.1\fP file in such that it is the target for \fBman foo\fP
+.P
+If the filename doesn't start with the package name, then it's prefixed\.
+So, this:
+.P
+.RS 2
+.nf
+{ "name" : "foo"
+, "version" : "1\.2\.3"
+, "description" : "A packaged foo fooer for fooing foos"
+, "main" : "foo\.js"
+, "man" : [ "\./man/foo\.1", "\./man/bar\.1" ]
+}
+.fi
+.RE
+.P
+will create files to do \fBman foo\fP and \fBman foo\-bar\fP\|\.
+.P
+Man files must end with a number, and optionally a \fB\|\.gz\fP suffix if they are
+compressed\.  The number dictates which man section the file is installed into\.
+.P
+.RS 2
+.nf
+{ "name" : "foo"
+, "version" : "1\.2\.3"
+, "description" : "A packaged foo fooer for fooing foos"
+, "main" : "foo\.js"
+, "man" : [ "\./man/foo\.1", "\./man/foo\.2" ]
+}
+.fi
+.RE
+.P
+will create entries for \fBman foo\fP and \fBman 2 foo\fP
+.SH directories
+.P
+The CommonJS Packages \fIhttp://wiki\.commonjs\.org/wiki/Packages/1\.0\fR spec details a
+few ways that you can indicate the structure of your package using a \fBdirectories\fP
+object\. If you look at npm's package\.json \fIhttps://registry\.npmjs\.org/npm/latest\fR,
+you'll see that it has directories for doc, lib, and man\.
+.P
+In the future, this information may be used in other creative ways\.
+.SS directories\.lib
+.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\.
+.SS directories\.bin
+.P
+If you specify a \fBbin\fP directory in \fBdirectories\.bin\fP, all the files in
+that folder will be added\.
+.P
+Because of the way the \fBbin\fP directive works, specifying both a
+\fBbin\fP path and setting \fBdirectories\.bin\fP is an error\. If you want to
+specify individual files, use \fBbin\fP, and for all the files in an
+existing \fBbin\fP directory, use \fBdirectories\.bin\fP\|\.
+.SS directories\.man
+.P
+A folder that is full of man pages\.  Sugar to generate a "man" array by
+walking the folder\.
+.SS directories\.doc
+.P
+Put markdown files in here\.  Eventually, these will be displayed nicely,
+maybe, someday\.
+.SS directories\.example
+.P
+Put example scripts in here\.  Someday, it might be exposed in some clever way\.
+.SS directories\.test
+.P
+Put your tests in here\. It is currently not exposed, but it might be in the
+future\.
+.SH repository
+.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 \fBnpm docs\fP
+command will be able to find you\.
+.P
+Do it like this:
+.P
+.RS 2
+.nf
+"repository": {
+  "type" : "git",
+  "url" : "https://github\.com/npm/cli\.git"
+}
+
+"repository": {
+  "type" : "svn",
+  "url" : "https://v8\.googlecode\.com/svn/trunk/"
+}
+.fi
+.RE
+.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
+For GitHub, GitHub gist, Bitbucket, or GitLab repositories you can use the same
+shortcut syntax you use for \fBnpm install\fP:
+.P
+.RS 2
+.nf
+"repository": "npm/npm"
+
+"repository": "github:user/repo"
+
+"repository": "gist:11081aaa281"
+
+"repository": "bitbucket:user/repo"
+
+"repository": "gitlab:user/repo"
+.fi
+.RE
+.SH scripts
+.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
+See npm help 7 \fBnpm\-scripts\fP to find out more about writing package scripts\.
+.SH config
+.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
+.RS 2
+.nf
+{ "name" : "foo"
+, "config" : { "port" : "8080" } }
+.fi
+.RE
+.P
+and then had a "start" command that then referenced the
+\fBnpm_package_config_port\fP environment variable, then the user could
+override that by doing \fBnpm config set foo:port 8001\fP\|\.
+.P
+See npm help 7 \fBnpm\-config\fP and npm help 7 \fBnpm\-scripts\fP for more on package
+configs\.
+.SH dependencies
+.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
+\fBPlease do not put test harnesses or transpilers in your
+\fBdependencies\fP object\.\fR  See \fBdevDependencies\fP, below\.
+.P
+See npm help 7 semver for more details about specifying version ranges\.
+.RS 0
+.IP \(bu 2
+\fBversion\fP Must match \fBversion\fP exactly
+.IP \(bu 2
+\fB>version\fP Must be greater than \fBversion\fP
+.IP \(bu 2
+\fB>=version\fP etc
+.IP \(bu 2
+\fB<version\fP
+.IP \(bu 2
+\fB<=version\fP
+.IP \(bu 2
+\fB~version\fP "Approximately equivalent to version"  See npm help 7 semver
+.IP \(bu 2
+\fB^version\fP "Compatible with version"  See npm help 7 semver
+.IP \(bu 2
+\fB1\.2\.x\fP 1\.2\.0, 1\.2\.1, etc\., but not 1\.3\.0
+.IP \(bu 2
+\fBhttp://\.\.\.\fP See 'URLs as Dependencies' below
+.IP \(bu 2
+\fB*\fP Matches any version
+.IP \(bu 2
+\fB""\fP (just an empty string) Same as \fB*\fP
+.IP \(bu 2
+\fBversion1 \- version2\fP Same as \fB>=version1 <=version2\fP\|\.
+.IP \(bu 2
+\fBrange1 || range2\fP Passes if either range1 or range2 are satisfied\.
+.IP \(bu 2
+\fBgit\.\.\.\fP See 'Git URLs as Dependencies' below
+.IP \(bu 2
+\fBuser/repo\fP See 'GitHub URLs' below
+.IP \(bu 2
+\fBtag\fP A specific version tagged and published as \fBtag\fP  See npm help \fBnpm\-dist\-tag\fP
+.IP \(bu 2
+\fBpath/path/path\fP See Local Paths \fI#local\-paths\fR below
+
+.RE
+.P
+For example, these are all valid:
+.P
+.RS 2
+.nf
+{ "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"
+  }
+}
+.fi
+.RE
+.SS URLs as Dependencies
+.P
+You may specify a tarball URL in place of a version range\.
+.P
+This tarball will be downloaded and installed locally to your package at
+install time\.
+.SS Git URLs as Dependencies
+.P
+Git urls are of the form:
+.P
+.RS 2
+.nf
+<protocol>://[<user>[:<password>]@]<hostname>[:<port>][:][/]<path>[#<commit\-ish> | #semver:<semver>]
+.fi
+.RE
+.P
+\fB<protocol>\fP is one of \fBgit\fP, \fBgit+ssh\fP, \fBgit+http\fP, \fBgit+https\fP, or
+\fBgit+file\fP\|\.
+.P
+If \fB#<commit\-ish>\fP is provided, it will be used to clone exactly that
+commit\. If the commit\-ish has the format \fB#semver:<semver>\fP, \fB<semver>\fP 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 \fB#<commit\-ish>\fP or \fB#semver:<semver>\fP is
+specified, then \fBmaster\fP is used\.
+.P
+Examples:
+.P
+.RS 2
+.nf
+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
+.fi
+.RE
+.SS GitHub URLs
+.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 \fBcommit\-ish\fP suffix can be
+included\.  For example:
+.P
+.RS 2
+.nf
+{
+  "name": "foo",
+  "version": "0\.0\.0",
+  "dependencies": {
+    "express": "expressjs/express",
+    "mocha": "mochajs/mocha#4727d357ea",
+    "module": "user/repo#feature\\/branch"
+  }
+}
+.fi
+.RE
+.SS Local Paths
+.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 \fBnpm install \-S\fP or
+\fBnpm install \-\-save\fP, using any of these forms:
+.P
+.RS 2
+.nf
+\|\.\./foo/bar
+~/foo/bar
+\|\./foo/bar
+/foo/bar
+.fi
+.RE
+.P
+in which case they will be normalized to a relative path and added to your
+\fBpackage\.json\fP\|\. For example:
+.P
+.RS 2
+.nf
+{
+  "name": "baz",
+  "dependencies": {
+    "bar": "file:\.\./foo/bar"
+  }
+}
+.fi
+.RE
+.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\.
+.SH devDependencies
+.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
+In this case, it's best to map these additional items in a \fBdevDependencies\fP
+object\.
+.P
+These things will be installed when doing \fBnpm link\fP or \fBnpm install\fP
+from the root of a package, and can be managed like any other npm
+configuration param\.  See npm help 7 \fBnpm\-config\fP for more on the topic\.
+.P
+For build steps that are not platform\-specific, such as compiling
+CoffeeScript or other languages to JavaScript, use the \fBprepare\fP
+script to do this, and make the required package a devDependency\.
+.P
+For example:
+.P
+.RS 2
+.nf
+{ "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"
+}
+.fi
+.RE
+.P
+The \fBprepare\fP 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 \fBnpm install\fP), it'll
+run this script as well, so that you can test it easily\.
+.SH peerDependencies
+.P
+In some cases, you want to express the compatibility of your package with a
+host tool or library, while not necessarily doing a \fBrequire\fP of this host\.
+This is usually referred to as a \fIplugin\fR\|\. Notably, your module may be exposing
+a specific interface, expected and specified by the host documentation\.
+.P
+For example:
+.P
+.RS 2
+.nf
+{
+  "name": "tea\-latte",
+  "version": "1\.3\.5",
+  "peerDependencies": {
+    "tea": "2\.x"
+  }
+}
+.fi
+.RE
+.P
+This ensures your package \fBtea\-latte\fP can be installed \fIalong\fR with the second
+major version of the host package \fBtea\fP only\. \fBnpm install tea\-latte\fP could
+possibly yield the following dependency graph:
+.P
+.RS 2
+.nf
+├── tea\-latte@1\.3\.5
+└── tea@2\.2\.0
+.fi
+.RE
+.P
+\fBNOTE: npm versions 1 and 2 will automatically install \fBpeerDependencies\fP 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\.\fR 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
+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
+Assuming the host complies with semver \fIhttps://semver\.org/\fR, 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 \fB"^1\.0"\fP or \fB"1\.x"\fP to express
+this\. If you depend on features introduced in 1\.5\.2, use \fB">= 1\.5\.2 < 2"\fP\|\.
+.SH bundledDependencies
+.P
+This defines an array of package names that will be bundled when publishing
+the package\.
+.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 \fBbundledDependencies\fP
+array and executing \fBnpm pack\fP\|\.
+.P
+For example:
+.P
+If we define a package\.json like this:
+.P
+.RS 2
+.nf
+{
+  "name": "awesome\-web\-framework",
+  "version": "1\.0\.0",
+  "bundledDependencies": [
+    "renderized", "super\-streams"
+  ]
+}
+.fi
+.RE
+.P
+we can obtain \fBawesome\-web\-framework\-1\.0\.0\.tgz\fP file by running \fBnpm pack\fP\|\.
+This file contains the dependencies \fBrenderized\fP and \fBsuper\-streams\fP which
+can be installed in a new project by executing \fBnpm install
+awesome\-web\-framework\-1\.0\.0\.tgz\fP\|\.
+.P
+If this is spelled \fB"bundleDependencies"\fP, then that is also honored\.
+.SH optionalDependencies
+.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 \fBoptionalDependencies\fP
+object\.  This is a map of package name to version or url, just like the
+\fBdependencies\fP object\.  The difference is that build failures do not cause
+installation to fail\.
+.P
+It is still your program's responsibility to handle the lack of the
+dependency\.  For example, something like this:
+.P
+.RS 2
+.nf
+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()
+}
+.fi
+.RE
+.P
+Entries in \fBoptionalDependencies\fP will override entries of the same name in
+\fBdependencies\fP, so it's usually best to only put in one place\.
+.SH engines
+.P
+You can specify the version of node that your stuff works on:
+.P
+.RS 2
+.nf
+{ "engines" : { "node" : ">=0\.10\.3 <0\.12" } }
+.fi
+.RE
+.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
+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
+You can also use the "engines" field to specify which versions of npm
+are capable of properly installing your program\.  For example:
+.P
+.RS 2
+.nf
+{ "engines" : { "npm" : "~1\.0\.20" } }
+.fi
+.RE
+.P
+Unless the user has set the \fBengine\-strict\fP config flag, this
+field is advisory only and will only produce warnings when your package is installed as a dependency\.
+.SH engineStrict
+.P
+\fBThis feature was removed in npm 3\.0\.0\fR
+.P
+Prior to npm 3\.0\.0, this feature was used to treat this package as if the
+user had set \fBengine\-strict\fP\|\. It is no longer used\.
+.SH os
+.P
+You can specify which operating systems your
+module will run on:
+.P
+.RS 2
+.nf
+"os" : [ "darwin", "linux" ]
+.fi
+.RE
+.P
+You can also blacklist instead of whitelist operating systems,
+just prepend the blacklisted os with a '!':
+.P
+.RS 2
+.nf
+"os" : [ "!win32" ]
+.fi
+.RE
+.P
+The host operating system is determined by \fBprocess\.platform\fP
+.P
+It is allowed to both blacklist, and whitelist, although there isn't any
+good reason to do this\.
+.SH cpu
+.P
+If your code only runs on certain cpu architectures,
+you can specify which ones\.
+.P
+.RS 2
+.nf
+"cpu" : [ "x64", "ia32" ]
+.fi
+.RE
+.P
+Like the \fBos\fP option, you can also blacklist architectures:
+.P
+.RS 2
+.nf
+"cpu" : [ "!arm", "!mips" ]
+.fi
+.RE
+.P
+The host architecture is determined by \fBprocess\.arch\fP
+.SH preferGlobal
+.P
+\fBDEPRECATED\fR
+.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\.
+.SH private
+.P
+If you set \fB"private": true\fP in your package\.json, then npm will refuse
+to publish it\.
+.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
+\fBpublishConfig\fP dictionary described below to override the \fBregistry\fP config
+param at publish\-time\.
+.SH publishConfig
+.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
+Any config values can be overridden, but only "tag", "registry" and "access"
+probably matter for the purposes of publishing\.
+.P
+See npm help 7 \fBnpm\-config\fP to see the list of config options that can be
+overridden\.
+.SH DEFAULT VALUES
+.P
+npm will default some values based on package contents\.
+.RS 0
+.IP \(bu 2
+\fB"scripts": {"start": "node server\.js"}\fP
+If there is a \fBserver\.js\fP file in the root of your package, then npm
+will default the \fBstart\fP command to \fBnode server\.js\fP\|\.
+.IP \(bu 2
+\fB"scripts":{"install": "node\-gyp rebuild"}\fP
+If there is a \fBbinding\.gyp\fP file in the root of your package and you have not defined an \fBinstall\fP or \fBpreinstall\fP script, npm will
+default the \fBinstall\fP command to compile using node\-gyp\.
+.IP \(bu 2
+\fB"contributors": [\.\.\.]\fP
+If there is an \fBAUTHORS\fP file in the root of your package, npm will
+treat each line as a \fBName <email> (url)\fP format, where email and url
+are optional\.  Lines which start with a \fB#\fP or are blank, will be
+ignored\.
+
+.RE
+.SH SEE ALSO
+.RS 0
+.IP \(bu 2
+npm help 7 semver
+.IP \(bu 2
+npm help init
+.IP \(bu 2
+npm help version
+.IP \(bu 2
+npm help config
+.IP \(bu 2
+npm help 7 config
+.IP \(bu 2
+npm help help
+.IP \(bu 2
+npm help install
+.IP \(bu 2
+npm help publish
+.IP \(bu 2
+npm help uninstall
+
+.RE
+