diff options
Diffstat (limited to 'deps/node/deps/npm/man/man5')
| -rw-r--r-- | deps/node/deps/npm/man/man5/npm-folders.5 | 226 | ||||
| -rw-r--r-- | deps/node/deps/npm/man/man5/npm-global.5 | 226 | ||||
| -rw-r--r-- | deps/node/deps/npm/man/man5/npm-json.5 | 966 | ||||
| -rw-r--r-- | deps/node/deps/npm/man/man5/npm-package-locks.5 | 198 | ||||
| -rw-r--r-- | deps/node/deps/npm/man/man5/npm-shrinkwrap.json.5 | 32 | ||||
| -rw-r--r-- | deps/node/deps/npm/man/man5/npmrc.5 | 109 | ||||
| -rw-r--r-- | deps/node/deps/npm/man/man5/package-lock.json.5 | 152 | ||||
| -rw-r--r-- | deps/node/deps/npm/man/man5/package.json.5 | 966 |
8 files changed, 0 insertions, 2875 deletions
diff --git a/deps/node/deps/npm/man/man5/npm-folders.5 b/deps/node/deps/npm/man/man5/npm-folders.5 deleted file mode 100644 index 0fa03d97..00000000 --- a/deps/node/deps/npm/man/man5/npm-folders.5 +++ /dev/null @@ -1,226 +0,0 @@ -.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 deleted file mode 100644 index 0fa03d97..00000000 --- a/deps/node/deps/npm/man/man5/npm-global.5 +++ /dev/null @@ -1,226 +0,0 @@ -.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 deleted file mode 100644 index dd20f7cb..00000000 --- a/deps/node/deps/npm/man/man5/npm-json.5 +++ /dev/null @@ -1,966 +0,0 @@ -.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 deleted file mode 100644 index b3692ceb..00000000 --- a/deps/node/deps/npm/man/man5/npm-package-locks.5 +++ /dev/null @@ -1,198 +0,0 @@ -.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 deleted file mode 100644 index c1d4db9a..00000000 --- a/deps/node/deps/npm/man/man5/npm-shrinkwrap.json.5 +++ /dev/null @@ -1,32 +0,0 @@ -.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 deleted file mode 100644 index 3d6bf7d5..00000000 --- a/deps/node/deps/npm/man/man5/npmrc.5 +++ /dev/null @@ -1,109 +0,0 @@ -.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 deleted file mode 100644 index dcb21542..00000000 --- a/deps/node/deps/npm/man/man5/package-lock.json.5 +++ /dev/null @@ -1,152 +0,0 @@ -.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 deleted file mode 100644 index dd20f7cb..00000000 --- a/deps/node/deps/npm/man/man5/package.json.5 +++ /dev/null @@ -1,966 +0,0 @@ -.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 - |