update packages to latest version

node_modules/npm/man/man1/npm-README.1

@@ -0,0 +1,181 @@
+.TH "NPM" "1" "March 2017" "" ""
+.SH "NAME"
+\fBnpm\fR \- a JavaScript package manager
+.P
+Build Status \fIhttps://img\.shields\.io/travis/npm/npm/master\.svg\fR \fIhttps://travis\-ci\.org/npm/npm\fR
+.SH SYNOPSIS
+.P
+This is just enough info to get you up and running\.
+.P
+Much more info available via \fBnpm help\fP once it's installed\.
+.SH IMPORTANT
+.P
+\fBYou need node v0\.10 or higher to run this program\.\fR
+.P
+To install an old \fBand unsupported\fR version of npm that works on node 0\.3
+and prior, clone the git repo and dig through the old tags and branches\.
+.P
+\fBnpm is configured to use npm, Inc\.'s public package registry at
+https://registry\.npmjs\.org by default\.\fR
+.P
+You can configure npm to use any compatible registry you
+like, and even run your own registry\. Check out the doc on
+registries \fIhttps://docs\.npmjs\.com/misc/registry\fR\|\.
+.P
+Use of someone else's registry may be governed by terms of use\. The
+terms of use for the default public registry are available at
+https://www\.npmjs\.com\|\.
+.SH Super Easy Install
+.P
+npm is bundled with node \fIhttp://nodejs\.org/download/\fR\|\.
+.SS Windows Computers
+.P
+Get the MSI \fIhttp://nodejs\.org/download/\fR\|\.  npm is in it\.
+.SS Apple Macintosh Computers
+.P
+Get the pkg \fIhttp://nodejs\.org/download/\fR\|\.  npm is in it\.
+.SS Other Sorts of Unices
+.P
+Run \fBmake install\fP\|\.  npm will be installed with node\.
+.P
+If you want a more fancy pants install (a different version, customized
+paths, etc\.) then read on\.
+.SH Fancy Install (Unix)
+.P
+There's a pretty robust install script at
+https://www\.npmjs\.com/install\.sh\|\.  You can download that and run it\.
+.P
+Here's an example using curl:
+.P
+.RS 2
+.nf
+curl \-L https://www\.npmjs\.com/install\.sh | sh
+.fi
+.RE
+.SS Slightly Fancier
+.P
+You can set any npm configuration params with that script:
+.P
+.RS 2
+.nf
+npm_config_prefix=/some/path sh install\.sh
+.fi
+.RE
+.P
+Or, you can run it in uber\-debuggery mode:
+.P
+.RS 2
+.nf
+npm_debug=1 sh install\.sh
+.fi
+.RE
+.SS Even Fancier
+.P
+Get the code with git\.  Use \fBmake\fP to build the docs and do other stuff\.
+If you plan on hacking on npm, \fBmake link\fP is your friend\.
+.P
+If you've got the npm source code, you can also semi\-permanently set
+arbitrary config keys using the \fB\|\./configure \-\-key=val \.\.\.\fP, and then
+run npm commands by doing \fBnode cli\.js <cmd> <args>\fP\|\.  (This is helpful
+for testing, or running stuff without actually installing npm itself\.)
+.SH Windows Install or Upgrade
+.P
+You can download a zip file from https://github\.com/npm/npm/releases, and
+unpack it in the \fBnode_modules\\npm\\\fP folder inside node's installation folder\.
+.P
+To upgrade to npm 2, follow the Windows upgrade instructions in
+the npm Troubleshooting Guide:
+.P
+https://github\.com/npm/npm/wiki/Troubleshooting#upgrading\-on\-windows
+.P
+If that's not fancy enough for you, then you can fetch the code with
+git, and mess with it directly\.
+.SH Installing on Cygwin
+.P
+No\.
+.SH Uninstalling
+.P
+So sad to see you go\.
+.P
+.RS 2
+.nf
+sudo npm uninstall npm \-g
+.fi
+.RE
+.P
+Or, if that fails,
+.P
+.RS 2
+.nf
+sudo make uninstall
+.fi
+.RE
+.SH More Severe Uninstalling
+.P
+Usually, the above instructions are sufficient\.  That will remove
+npm, but leave behind anything you've installed\.
+.P
+If you would like to remove all the packages that you have installed,
+then you can use the \fBnpm ls\fP command to find them, and then \fBnpm rm\fP to
+remove them\.
+.P
+To remove cruft left behind by npm 0\.x, you can use the included
+\fBclean\-old\.sh\fP script file\.  You can run it conveniently like this:
+.P
+.RS 2
+.nf
+npm explore npm \-g \-\- sh scripts/clean\-old\.sh
+.fi
+.RE
+.P
+npm uses two configuration files, one for per\-user configs, and another
+for global (every\-user) configs\.  You can view them by doing:
+.P
+.RS 2
+.nf
+npm config get userconfig   # defaults to ~/\.npmrc
+npm config get globalconfig # defaults to /usr/local/etc/npmrc
+.fi
+.RE
+.P
+Uninstalling npm does not remove configuration files by default\.  You
+must remove them yourself manually if you want them gone\.  Note that
+this means that future npm installs will not remember the settings that
+you have chosen\.
+.SH More Docs
+.P
+Check out the docs \fIhttps://docs\.npmjs\.com/\fR,
+especially the faq \fIhttps://docs\.npmjs\.com/misc/faq\fR\|\.
+.P
+You can use the \fBnpm help\fP command to read any of them\.
+.P
+If you're a developer, and you want to use npm to publish your program,
+you should read this \fIhttps://docs\.npmjs\.com/misc/developers\fR
+.SH BUGS
+.P
+When you find issues, please report them:
+.RS 0
+.IP \(bu 2
+web:
+https://github\.com/npm/npm/issues
+
+.RE
+.P
+Be sure to include \fIall\fR of the output from the npm command that didn't work
+as expected\.  The \fBnpm\-debug\.log\fP file is also helpful to provide\.
+.P
+You can also look for isaacs in #node\.js on irc://irc\.freenode\.net\.  He
+will no doubt tell you to put the output in a gist or email\.
+.SH SEE ALSO
+.RS 0
+.IP \(bu 2
+npm help npm
+.IP \(bu 2
+npm help 7 faq
+.IP \(bu 2
+npm help help
+.IP \(bu 2
+npm help 7 index
+
+.RE
+

node_modules/npm/man/man1/npm-access.1

@@ -0,0 +1,89 @@
+.TH "NPM\-ACCESS" "1" "March 2017" "" ""
+.SH "NAME"
+\fBnpm-access\fR \- Set access level on published packages
+.SH SYNOPSIS
+.P
+.RS 2
+.nf
+npm access public [<package>]
+npm access restricted [<package>]
+
+npm access grant <read\-only|read\-write> <scope:team> [<package>]
+npm access revoke <scope:team> [<package>]
+
+npm access ls\-packages [<user>|<scope>|<scope:team>]
+npm access ls\-collaborators [<package> [<user>]]
+npm access edit [<package>]
+.fi
+.RE
+.SH DESCRIPTION
+.P
+Used to set access controls on private packages\.
+.P
+For all of the subcommands, \fBnpm access\fP will perform actions on the packages
+in the current working directory if no package name is passed to the
+subcommand\.
+.RS 0
+.IP \(bu 2
+public / restricted:
+Set a package to be either publicly accessible or restricted\.
+.IP \(bu 2
+grant / revoke:
+Add or remove the ability of users and teams to have read\-only or read\-write
+access to a package\.
+.IP \(bu 2
+ls\-packages:
+Show all of the packages a user or a team is able to access, along with the
+access level, except for read\-only public packages (it won't print the whole
+registry listing)
+.IP \(bu 2
+ls\-collaborators:
+Show all of the access privileges for a package\. Will only show permissions
+for packages to which you have at least read access\. If \fB<user>\fP is passed in,
+the list is filtered only to teams \fIthat\fR user happens to belong to\.
+.IP \(bu 2
+edit:
+Set the access privileges for a package at once using \fB$EDITOR\fP\|\.
+
+.RE
+.SH DETAILS
+.P
+\fBnpm access\fP always operates directly on the current registry, configurable
+from the command line using \fB\-\-registry=<registry url>\fP\|\.
+.P
+Unscoped packages are \fIalways public\fR\|\.
+.P
+Scoped packages \fIdefault to restricted\fR, but you can either publish them as
+public using \fBnpm publish \-\-access=public\fP, or set their access as public using
+\fBnpm access public\fP after the initial publish\.
+.P
+You must have privileges to set the access of a package:
+.RS 0
+.IP \(bu 2
+You are an owner of an unscoped or scoped package\.
+.IP \(bu 2
+You are a member of the team that owns a scope\.
+.IP \(bu 2
+You have been given read\-write privileges for a package, either as a member
+of a team or directly as an owner\.
+
+.RE
+.P
+If your account is not paid, then attempts to publish scoped packages will fail
+with an HTTP 402 status code (logically enough), unless you use
+\fB\-\-access=public\fP\|\.
+.P
+Management of teams and team memberships is done with the \fBnpm team\fP command\.
+.SH SEE ALSO
+.RS 0
+.IP \(bu 2
+npm help team
+.IP \(bu 2
+npm help publish
+.IP \(bu 2
+npm help 7 config
+.IP \(bu 2
+npm help 7 registry
+
+.RE
+

node_modules/npm/man/man1/npm-adduser.1

@@ -0,0 +1,90 @@
+.TH "NPM\-ADDUSER" "1" "March 2017" "" ""
+.SH "NAME"
+\fBnpm-adduser\fR \- Add a registry user account
+.SH SYNOPSIS
+.P
+.RS 2
+.nf
+npm adduser [\-\-registry=url] [\-\-scope=@orgname] [\-\-always\-auth]
+
+aliases: login, add\-user
+.fi
+.RE
+.SH DESCRIPTION
+.P
+Create or verify a user named \fB<username>\fP in the specified registry, and
+save the credentials to the \fB\|\.npmrc\fP file\. If no registry is specified,
+the default registry will be used (see npm help 7 \fBnpm\-config\fP)\.
+.P
+The username, password, and email are read in from prompts\.
+.P
+To reset your password, go to https://www\.npmjs\.com/forgot
+.P
+To change your email address, go to https://www\.npmjs\.com/email\-edit
+.P
+You may use this command multiple times with the same user account to
+authorize on a new machine\.  When authenticating on a new machine,
+the username, password and email address must all match with
+your existing record\.
+.P
+\fBnpm login\fP is an alias to \fBadduser\fP and behaves exactly the same way\.
+.SH CONFIGURATION
+.SS registry
+.P
+Default: https://registry\.npmjs\.org/
+.P
+The base URL of the npm package registry\. If \fBscope\fP is also specified,
+this registry will only be used for packages with that scope\. See npm help 7 \fBnpm\-scope\fP\|\.
+.SS scope
+.P
+Default: none
+.P
+If specified, the user and login credentials given will be associated
+with the specified scope\. See npm help 7 \fBnpm\-scope\fP\|\. You can use both at the same time,
+e\.g\.
+.P
+.RS 2
+.nf
+npm adduser \-\-registry=http://myregistry\.example\.com \-\-scope=@myco
+.fi
+.RE
+.P
+This will set a registry for the given scope and login or create a user for
+that registry at the same time\.
+.SS always\-auth
+.P
+Default: false
+.P
+If specified, save configuration indicating that all requests to the given
+registry should include authorization information\. Useful for private
+registries\. Can be used with \fB\-\-registry\fP and / or \fB\-\-scope\fP, e\.g\.
+.P
+.RS 2
+.nf
+npm adduser \-\-registry=http://private\-registry\.example\.com \-\-always\-auth
+.fi
+.RE
+.P
+This will ensure that all requests to that registry (including for tarballs)
+include an authorization header\. This setting may be necessary for use with
+private registries where metadata and package tarballs are stored on hosts with
+different hostnames\. See \fBalways\-auth\fP in npm help 7 \fBnpm\-config\fP for more details on
+always\-auth\. Registry\-specific configuration of \fBalways\-auth\fP takes precedence
+over any global configuration\.
+.SH SEE ALSO
+.RS 0
+.IP \(bu 2
+npm help 7 registry
+.IP \(bu 2
+npm help config
+.IP \(bu 2
+npm help 7 config
+.IP \(bu 2
+npm help 5 npmrc
+.IP \(bu 2
+npm help owner
+.IP \(bu 2
+npm help whoami
+
+.RE
+

node_modules/npm/man/man1/npm-bin.1

@@ -0,0 +1,30 @@
+.TH "NPM\-BIN" "1" "March 2017" "" ""
+.SH "NAME"
+\fBnpm-bin\fR \- Display npm bin folder
+.SH SYNOPSIS
+.P
+.RS 2
+.nf
+npm bin
+.fi
+.RE
+.SH DESCRIPTION
+.P
+Print the folder where npm will install executables\.
+.SH SEE ALSO
+.RS 0
+.IP \(bu 2
+npm help prefix
+.IP \(bu 2
+npm help root
+.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 npmrc
+
+.RE
+

node_modules/npm/man/man1/npm-bugs.1

@@ -0,0 +1,61 @@
+.TH "NPM\-BUGS" "1" "March 2017" "" ""
+.SH "NAME"
+\fBnpm-bugs\fR \- Bugs for a package in a web browser maybe
+.SH SYNOPSIS
+.P
+.RS 2
+.nf
+npm bugs <pkgname>
+npm bugs (with no args in a package dir)
+
+aliases: issues
+.fi
+.RE
+.SH DESCRIPTION
+.P
+This command tries to guess at the likely location of a package's
+bug tracker URL, and then tries to open it using the \fB\-\-browser\fP
+config param\. If no package name is provided, it will search for
+a \fBpackage\.json\fP in the current folder and use the \fBname\fP property\.
+.SH CONFIGURATION
+.SS browser
+.RS 0
+.IP \(bu 2
+Default: OS X: \fB"open"\fP, Windows: \fB"start"\fP, Others: \fB"xdg\-open"\fP
+.IP \(bu 2
+Type: String
+
+.RE
+.P
+The browser that is called by the \fBnpm bugs\fP command to open websites\.
+.SS registry
+.RS 0
+.IP \(bu 2
+Default: https://registry\.npmjs\.org/
+.IP \(bu 2
+Type: url
+
+.RE
+.P
+The base URL of the npm package registry\.
+.SH SEE ALSO
+.RS 0
+.IP \(bu 2
+npm help docs
+.IP \(bu 2
+npm help view
+.IP \(bu 2
+npm help publish
+.IP \(bu 2
+npm help 7 registry
+.IP \(bu 2
+npm help config
+.IP \(bu 2
+npm help 7 config
+.IP \(bu 2
+npm help 5 npmrc
+.IP \(bu 2
+npm help 5 package\.json
+
+.RE
+

node_modules/npm/man/man1/npm-build.1

@@ -0,0 +1,41 @@
+.TH "NPM\-BUILD" "1" "March 2017" "" ""
+.SH "NAME"
+\fBnpm-build\fR \- Build a package
+.SH SYNOPSIS
+.P
+.RS 2
+.nf
+npm build <package\-folder>
+.fi
+.RE
+.RS 0
+.IP \(bu 2
+\fB<package\-folder>\fP:
+A folder containing a \fBpackage\.json\fP file in its root\.
+
+.RE
+.SH DESCRIPTION
+.P
+This is the plumbing command called by \fBnpm link\fP and \fBnpm install\fP\|\.
+.P
+It should generally be called during installation, but if you need to run it
+directly, run:
+.P
+.RS 2
+.nf
+npm run\-script build
+.fi
+.RE
+.SH SEE ALSO
+.RS 0
+.IP \(bu 2
+npm help install
+.IP \(bu 2
+npm help link
+.IP \(bu 2
+npm help 7 scripts
+.IP \(bu 2
+npm help 5 package\.json
+
+.RE
+

node_modules/npm/man/man1/npm-bundle.1

@@ -0,0 +1,17 @@
+.TH "NPM\-BUNDLE" "1" "March 2017" "" ""
+.SH "NAME"
+\fBnpm-bundle\fR \- REMOVED
+.SH DESCRIPTION
+.P
+The \fBnpm bundle\fP command has been removed in 1\.0, for the simple reason
+that it is no longer necessary, as the default behavior is now to
+install packages into the local space\.
+.P
+Just use \fBnpm install\fP now to do what \fBnpm bundle\fP used to do\.
+.SH SEE ALSO
+.RS 0
+.IP \(bu 2
+npm help install
+
+.RE
+

node_modules/npm/man/man1/npm-cache.1

@@ -0,0 +1,86 @@
+.TH "NPM\-CACHE" "1" "March 2017" "" ""
+.SH "NAME"
+\fBnpm-cache\fR \- Manipulates packages cache
+.SH SYNOPSIS
+.P
+.RS 2
+.nf
+npm cache add <tarball file>
+npm cache add <folder>
+npm cache add <tarball url>
+npm cache add <name>@<version>
+
+npm cache ls [<path>]
+
+npm cache clean [<path>]
+.fi
+.RE
+.SH DESCRIPTION
+.P
+Used to add, list, or clear the npm cache folder\.
+.RS 0
+.IP \(bu 2
+add:
+Add the specified package to the local cache\.  This command is primarily
+intended to be used internally by npm, but it can provide a way to
+add data to the local installation cache explicitly\.
+.IP \(bu 2
+ls:
+Show the data in the cache\.  Argument is a path to show in the cache
+folder\.  Works a bit like the \fBfind\fP program, but limited by the
+\fBdepth\fP config\.
+.IP \(bu 2
+clean:
+Delete data out of the cache folder\.  If an argument is provided, then
+it specifies a subpath to delete\.  If no argument is provided, then
+the entire cache is cleared\.
+
+.RE
+.SH DETAILS
+.P
+npm stores cache data in the directory specified in \fBnpm config get cache\fP\|\.
+For each package that is added to the cache, three pieces of information are
+stored in \fB{cache}/{name}/{version}\fP:
+.RS 0
+.IP \(bu 2
+\|\.\.\./package/package\.json:
+The package\.json file, as npm sees it\.
+.IP \(bu 2
+\|\.\.\./package\.tgz:
+The tarball for that version\.
+
+.RE
+.P
+Additionally, whenever a registry request is made, a \fB\|\.cache\.json\fP file
+is placed at the corresponding URI, to store the ETag and the requested
+data\.  This is stored in \fB{cache}/{hostname}/{path}/\.cache\.json\fP\|\.
+.P
+Commands that make non\-essential registry requests (such as \fBsearch\fP and
+\fBview\fP, or the completion scripts) generally specify a minimum timeout\.
+If the \fB\|\.cache\.json\fP file is younger than the specified timeout, then
+they do not make an HTTP request to the registry\.
+.SH CONFIGURATION
+.SS cache
+.P
+Default: \fB~/\.npm\fP on Posix, or \fB%AppData%/npm\-cache\fP on Windows\.
+.P
+The root cache folder\.
+.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 npmrc
+.IP \(bu 2
+npm help install
+.IP \(bu 2
+npm help publish
+.IP \(bu 2
+npm help pack
+
+.RE
+

node_modules/npm/man/man1/npm-completion.1

@@ -0,0 +1,37 @@
+.TH "NPM\-COMPLETION" "1" "March 2017" "" ""
+.SH "NAME"
+\fBnpm-completion\fR \- Tab Completion for npm
+.SH SYNOPSIS
+.P
+.RS 2
+.nf
+\|\. <(npm completion)
+.fi
+.RE
+.SH DESCRIPTION
+.P
+Enables tab\-completion in all npm commands\.
+.P
+The synopsis above
+loads the completions into your current shell\.  Adding it to
+your ~/\.bashrc or ~/\.zshrc will make the completions available
+everywhere\.
+.P
+You may of course also pipe the output of npm completion to a file
+such as \fB/usr/local/etc/bash_completion\.d/npm\fP if you have a system
+that will read that file for you\.
+.P
+When \fBCOMP_CWORD\fP, \fBCOMP_LINE\fP, and \fBCOMP_POINT\fP are defined in the
+environment, \fBnpm completion\fP acts in "plumbing mode", and outputs
+completions based on the arguments\.
+.SH SEE ALSO
+.RS 0
+.IP \(bu 2
+npm help 7 developers
+.IP \(bu 2
+npm help 7 faq
+.IP \(bu 2
+npm help npm
+
+.RE
+

node_modules/npm/man/man1/npm-config.1

@@ -0,0 +1,97 @@
+.TH "NPM\-CONFIG" "1" "March 2017" "" ""
+.SH "NAME"
+\fBnpm-config\fR \- Manage the npm configuration files
+.SH SYNOPSIS
+.P
+.RS 2
+.nf
+npm config set <key> <value> [\-\-global]
+npm config get <key>
+npm config delete <key>
+npm config list
+npm config edit
+npm c [set|get|delete|list]
+npm get <key>
+npm set <key> <value> [\-\-global]
+
+aliases: c
+.fi
+.RE
+.SH DESCRIPTION
+.P
+npm gets its config settings from the command line, environment
+variables, \fBnpmrc\fP files, and in some cases, the \fBpackage\.json\fP file\.
+.P
+See npm help 5 npmrc for more information about the npmrc files\.
+.P
+See npm help 7 \fBnpm\-config\fP for a more thorough discussion of the mechanisms
+involved\.
+.P
+The \fBnpm config\fP command can be used to update and edit the contents
+of the user and global npmrc files\.
+.SH Sub\-commands
+.P
+Config supports the following sub\-commands:
+.SS set
+.P
+.RS 2
+.nf
+npm config set key value
+.fi
+.RE
+.P
+Sets the config key to the value\.
+.P
+If value is omitted, then it sets it to "true"\.
+.SS get
+.P
+.RS 2
+.nf
+npm config get key
+.fi
+.RE
+.P
+Echo the config value to stdout\.
+.SS list
+.P
+.RS 2
+.nf
+npm config list
+.fi
+.RE
+.P
+Show all the config settings\.
+.SS delete
+.P
+.RS 2
+.nf
+npm config delete key
+.fi
+.RE
+.P
+Deletes the key from all configuration files\.
+.SS edit
+.P
+.RS 2
+.nf
+npm config edit
+.fi
+.RE
+.P
+Opens the config file in an editor\.  Use the \fB\-\-global\fP flag to edit the
+global config\.
+.SH SEE ALSO
+.RS 0
+.IP \(bu 2
+npm help 5 folders
+.IP \(bu 2
+npm help 7 config
+.IP \(bu 2
+npm help 5 package\.json
+.IP \(bu 2
+npm help 5 npmrc
+.IP \(bu 2
+npm help npm
+
+.RE
+

node_modules/npm/man/man1/npm-dedupe.1

@@ -0,0 +1,76 @@
+.TH "NPM\-DEDUPE" "1" "March 2017" "" ""
+.SH "NAME"
+\fBnpm-dedupe\fR \- Reduce duplication
+.SH SYNOPSIS
+.P
+.RS 2
+.nf
+npm dedupe [package names\.\.\.]
+npm ddp [package names\.\.\.]
+
+aliases: find\-dupes, ddp
+.fi
+.RE
+.SH DESCRIPTION
+.P
+Searches the local package tree and attempts to simplify the overall
+structure by moving dependencies further up the tree, where they can
+be more effectively shared by multiple dependent packages\.
+.P
+For example, consider this dependency graph:
+.P
+.RS 2
+.nf
+a
++\-\- b <\-\- depends on c@1\.0\.x
+|   `\-\- c@1\.0\.3
+`\-\- d <\-\- depends on c@~1\.0\.9
+    `\-\- c@1\.0\.10
+.fi
+.RE
+.P
+In this case, npm help \fBnpm\-dedupe\fP will transform the tree to:
+.P
+.RS 2
+.nf
+a
++\-\- b
++\-\- d
+`\-\- c@1\.0\.10
+.fi
+.RE
+.P
+Because of the hierarchical nature of node's module lookup, b and d
+will both get their dependency met by the single c package at the root
+level of the tree\.
+.P
+If a suitable version exists at the target location in the tree
+already, then it will be left untouched, but the other duplicates will
+be deleted\.
+.P
+If no suitable version can be found, then a warning is printed, and
+nothing is done\.
+.P
+If any arguments are supplied, then they are filters, and only the
+named packages will be touched\.
+.P
+Note that this operation transforms the dependency tree, and may
+result in packages getting updated versions, perhaps from the npm
+registry\.
+.P
+This feature is experimental, and may change in future versions\.
+.P
+The \fB\-\-tag\fP argument will apply to all of the affected dependencies\. If a
+tag with the given name exists, the tagged version is preferred over newer
+versions\.
+.SH SEE ALSO
+.RS 0
+.IP \(bu 2
+npm help ls
+.IP \(bu 2
+npm help update
+.IP \(bu 2
+npm help install
+
+.RE
+

node_modules/npm/man/man1/npm-deprecate.1

@@ -0,0 +1,37 @@
+.TH "NPM\-DEPRECATE" "1" "March 2017" "" ""
+.SH "NAME"
+\fBnpm-deprecate\fR \- Deprecate a version of a package
+.SH SYNOPSIS
+.P
+.RS 2
+.nf
+npm deprecate <name>[@<version>] <message>
+.fi
+.RE
+.SH DESCRIPTION
+.P
+This command will update the npm registry entry for a package, providing
+a deprecation warning to all who attempt to install it\.
+.P
+It works on version ranges as well as specific versions, so you can do
+something like this:
+.P
+.RS 2
+.nf
+npm deprecate my\-thing@"< 0\.2\.3" "critical bug fixed in v0\.2\.3"
+.fi
+.RE
+.P
+Note that you must be the package owner to deprecate something\.  See the
+\fBowner\fP and \fBadduser\fP help topics\.
+.P
+To un\-deprecate a package, specify an empty string (\fB""\fP) for the \fBmessage\fP argument\.
+.SH SEE ALSO
+.RS 0
+.IP \(bu 2
+npm help publish
+.IP \(bu 2
+npm help 7 registry
+
+.RE
+

node_modules/npm/man/man1/npm-dist-tag.1

@@ -0,0 +1,109 @@
+.TH "NPM\-DIST\-TAG" "1" "March 2017" "" ""
+.SH "NAME"
+\fBnpm-dist-tag\fR \- Modify package distribution tags
+.SH SYNOPSIS
+.P
+.RS 2
+.nf
+npm dist\-tag add <pkg>@<version> [<tag>]
+npm dist\-tag rm <pkg> <tag>
+npm dist\-tag ls [<pkg>]
+
+aliases: dist\-tags
+.fi
+.RE
+.SH DESCRIPTION
+.P
+Add, remove, and enumerate distribution tags on a package:
+.RS 0
+.IP \(bu 2
+add:
+Tags the specified version of the package with the specified tag, or the
+\fB\-\-tag\fP config if not specified\.
+.IP \(bu 2
+rm:
+Clear a tag that is no longer in use from the package\.
+.IP \(bu 2
+ls:
+Show all of the dist\-tags for a package, defaulting to the package in
+the current prefix\.
+
+.RE
+.P
+A tag can be used when installing packages as a reference to a version instead
+of using a specific version number:
+.P
+.RS 2
+.nf
+npm install <name>@<tag>
+.fi
+.RE
+.P
+When installing dependencies, a preferred tagged version may be specified:
+.P
+.RS 2
+.nf
+npm install \-\-tag <tag>
+.fi
+.RE
+.P
+This also applies to \fBnpm dedupe\fP\|\.
+.P
+Publishing a package sets the \fBlatest\fP tag to the published version unless the
+\fB\-\-tag\fP option is used\. For example, \fBnpm publish \-\-tag=beta\fP\|\.
+.P
+By default, \fBnpm install <pkg>\fP (without any \fB@<version>\fP or \fB@<tag>\fP
+specifier) installs the \fBlatest\fP tag\.
+.SH PURPOSE
+.P
+Tags can be used to provide an alias instead of version numbers\.
+.P
+For example, a project might choose to have multiple streams of development
+and use a different tag for each stream,
+e\.g\., \fBstable\fP, \fBbeta\fP, \fBdev\fP, \fBcanary\fP\|\.
+.P
+By default, the \fBlatest\fP tag is used by npm to identify the current version of
+a package, and \fBnpm install <pkg>\fP (without any \fB@<version>\fP or \fB@<tag>\fP
+specifier) installs the \fBlatest\fP tag\. Typically, projects only use the \fBlatest\fP
+tag for stable release versions, and use other tags for unstable versions such
+as prereleases\.
+.P
+The \fBnext\fP tag is used by some projects to identify the upcoming version\.
+.P
+By default, other than \fBlatest\fP, no tag has any special significance to npm
+itself\.
+.SH CAVEATS
+.P
+This command used to be known as \fBnpm tag\fP, which only created new tags, and so
+had a different syntax\.
+.P
+Tags must share a namespace with version numbers, because they are specified in
+the same slot: \fBnpm install <pkg>@<version>\fP vs \fBnpm install <pkg>@<tag>\fP\|\.
+.P
+Tags that can be interpreted as valid semver ranges will be rejected\. For
+example, \fBv1\.4\fP cannot be used as a tag, because it is interpreted by semver as
+\fB>=1\.4\.0 <1\.5\.0\fP\|\.  See https://github\.com/npm/npm/issues/6082\|\.
+.P
+The simplest way to avoid semver problems with tags is to use tags that do not
+begin with a number or the letter \fBv\fP\|\.
+.SH SEE ALSO
+.RS 0
+.IP \(bu 2
+npm help tag
+.IP \(bu 2
+npm help publish
+.IP \(bu 2
+npm help install
+.IP \(bu 2
+npm help dedupe
+.IP \(bu 2
+npm help 7 registry
+.IP \(bu 2
+npm help config
+.IP \(bu 2
+npm help 7 config
+.IP \(bu 2
+npm help 5 npmrc
+
+.RE
+

node_modules/npm/man/man1/npm-docs.1

@@ -0,0 +1,60 @@
+.TH "NPM\-DOCS" "1" "March 2017" "" ""
+.SH "NAME"
+\fBnpm-docs\fR \- Docs for a package in a web browser maybe
+.SH SYNOPSIS
+.P
+.RS 2
+.nf
+npm docs [<pkgname> [<pkgname> \.\.\.]]
+npm docs (with no args in a package dir)
+npm home [<pkgname> [<pkgname> \.\.\.]]
+npm home (with no args in a package dir)
+.fi
+.RE
+.SH DESCRIPTION
+.P
+This command tries to guess at the likely location of a package's
+documentation URL, and then tries to open it using the \fB\-\-browser\fP
+config param\. You can pass multiple package names at once\. If no
+package name is provided, it will search for a \fBpackage\.json\fP in
+the current folder and use the \fBname\fP property\.
+.SH CONFIGURATION
+.SS browser
+.RS 0
+.IP \(bu 2
+Default: OS X: \fB"open"\fP, Windows: \fB"start"\fP, Others: \fB"xdg\-open"\fP
+.IP \(bu 2
+Type: String
+
+.RE
+.P
+The browser that is called by the \fBnpm docs\fP command to open websites\.
+.SS registry
+.RS 0
+.IP \(bu 2
+Default: https://registry\.npmjs\.org/
+.IP \(bu 2
+Type: url
+
+.RE
+.P
+The base URL of the npm package registry\.
+.SH SEE ALSO
+.RS 0
+.IP \(bu 2
+npm help view
+.IP \(bu 2
+npm help publish
+.IP \(bu 2
+npm help 7 registry
+.IP \(bu 2
+npm help config
+.IP \(bu 2
+npm help 7 config
+.IP \(bu 2
+npm help 5 npmrc
+.IP \(bu 2
+npm help 5 package\.json
+
+.RE
+

node_modules/npm/man/man1/npm-edit.1

@@ -0,0 +1,50 @@
+.TH "NPM\-EDIT" "1" "March 2017" "" ""
+.SH "NAME"
+\fBnpm-edit\fR \- Edit an installed package
+.SH SYNOPSIS
+.P
+.RS 2
+.nf
+npm edit <name>[@<version>]
+.fi
+.RE
+.SH DESCRIPTION
+.P
+Opens the package folder in the default editor (or whatever you've
+configured as the npm \fBeditor\fP config \-\- see npm help 7 \fBnpm\-config\fP\|\.)
+.P
+After it has been edited, the package is rebuilt so as to pick up any
+changes in compiled packages\.
+.P
+For instance, you can do \fBnpm install connect\fP to install connect
+into your package, and then \fBnpm edit connect\fP to make a few
+changes to your locally installed copy\.
+.SH CONFIGURATION
+.SS editor
+.RS 0
+.IP \(bu 2
+Default: \fBEDITOR\fP environment variable if set, or \fB"vi"\fP on Posix,
+or \fB"notepad"\fP on Windows\.
+.IP \(bu 2
+Type: path
+
+.RE
+.P
+The command to run for \fBnpm edit\fP or \fBnpm config edit\fP\|\.
+.SH SEE ALSO
+.RS 0
+.IP \(bu 2
+npm help 5 folders
+.IP \(bu 2
+npm help explore
+.IP \(bu 2
+npm help install
+.IP \(bu 2
+npm help config
+.IP \(bu 2
+npm help 7 config
+.IP \(bu 2
+npm help 5 npmrc
+
+.RE
+

node_modules/npm/man/man1/npm-explore.1

@@ -0,0 +1,55 @@
+.TH "NPM\-EXPLORE" "1" "March 2017" "" ""
+.SH "NAME"
+\fBnpm-explore\fR \- Browse an installed package
+.SH SYNOPSIS
+.P
+.RS 2
+.nf
+npm explore <name> [ \-\- <cmd>]
+.fi
+.RE
+.SH DESCRIPTION
+.P
+Spawn a subshell in the directory of the installed package specified\.
+.P
+If a command is specified, then it is run in the subshell, which then
+immediately terminates\.
+.P
+This is particularly handy in the case of git submodules in the
+\fBnode_modules\fP folder:
+.P
+.RS 2
+.nf
+npm explore some\-dependency \-\- git pull origin master
+.fi
+.RE
+.P
+Note that the package is \fInot\fR automatically rebuilt afterwards, so be
+sure to use \fBnpm rebuild <pkg>\fP if you make any changes\.
+.SH CONFIGURATION
+.SS shell
+.RS 0
+.IP \(bu 2
+Default: SHELL environment variable, or "bash" on Posix, or "cmd" on
+Windows
+.IP \(bu 2
+Type: path
+
+.RE
+.P
+The shell to run for the \fBnpm explore\fP command\.
+.SH SEE ALSO
+.RS 0
+.IP \(bu 2
+npm help 5 folders
+.IP \(bu 2
+npm help edit
+.IP \(bu 2
+npm help rebuild
+.IP \(bu 2
+npm help build
+.IP \(bu 2
+npm help install
+
+.RE
+

node_modules/npm/man/man1/npm-help-search.1

@@ -0,0 +1,45 @@
+.TH "NPM\-HELP\-SEARCH" "1" "March 2017" "" ""
+.SH "NAME"
+\fBnpm-help-search\fR \- Search npm help documentation
+.SH SYNOPSIS
+.P
+.RS 2
+.nf
+npm help\-search some search terms
+.fi
+.RE
+.SH DESCRIPTION
+.P
+This command will search the npm markdown documentation files for the
+terms provided, and then list the results, sorted by relevance\.
+.P
+If only one result is found, then it will show that help topic\.
+.P
+If the argument to \fBnpm help\fP is not a known help topic, then it will
+call \fBhelp\-search\fP\|\.  It is rarely if ever necessary to call this
+command directly\.
+.SH CONFIGURATION
+.SS long
+.RS 0
+.IP \(bu 2
+Type: Boolean
+.IP \(bu 2
+Default: false
+
+.RE
+.P
+If true, the "long" flag will cause help\-search to output context around
+where the terms were found in the documentation\.
+.P
+If false, then help\-search will just list out the help topics found\.
+.SH SEE ALSO
+.RS 0
+.IP \(bu 2
+npm help npm
+.IP \(bu 2
+npm help 7 faq
+.IP \(bu 2
+npm help help
+
+.RE
+

node_modules/npm/man/man1/npm-help.1

@@ -0,0 +1,57 @@
+.TH "NPM\-HELP" "1" "March 2017" "" ""
+.SH "NAME"
+\fBnpm-help\fR \- Get help on npm
+.SH SYNOPSIS
+.P
+.RS 2
+.nf
+npm help <topic>
+npm help some search terms
+.fi
+.RE
+.SH DESCRIPTION
+.P
+If supplied a topic, then show the appropriate documentation page\.
+.P
+If the topic does not exist, or if multiple terms are provided, then run
+the \fBhelp\-search\fP command to find a match\.  Note that, if \fBhelp\-search\fP
+finds a single subject, then it will run \fBhelp\fP on that topic, so unique
+matches are equivalent to specifying a topic name\.
+.SH CONFIGURATION
+.SS viewer
+.RS 0
+.IP \(bu 2
+Default: "man" on Posix, "browser" on Windows
+.IP \(bu 2
+Type: path
+
+.RE
+.P
+The program to use to view help content\.
+.P
+Set to \fB"browser"\fP to view html help content in the default web browser\.
+.SH SEE ALSO
+.RS 0
+.IP \(bu 2
+npm help npm
+.IP \(bu 2
+README
+.IP \(bu 2
+npm help 7 faq
+.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 npmrc
+.IP \(bu 2
+npm help 5 package\.json
+.IP \(bu 2
+npm help help\-search
+.IP \(bu 2
+npm help 7 index
+
+.RE
+

node_modules/npm/man/man1/npm-init.1

@@ -0,0 +1,49 @@
+.TH "NPM\-INIT" "1" "March 2017" "" ""
+.SH "NAME"
+\fBnpm-init\fR \- Interactively create a package\.json file
+.SH SYNOPSIS
+.P
+.RS 2
+.nf
+npm init [\-f|\-\-force|\-y|\-\-yes]
+.fi
+.RE
+.SH DESCRIPTION
+.P
+This will ask you a bunch of questions, and then write a package\.json for you\.
+.P
+It attempts to make reasonable guesses about what you want things to be set to,
+and then writes a package\.json file with the options you've selected\.
+.P
+If you already have a package\.json file, it'll read that first, and default to
+the options in there\.
+.P
+It is strictly additive, so it does not delete options from your package\.json
+without a really good reason to do so\.
+.P
+If you invoke it with \fB\-f\fP, \fB\-\-force\fP, \fB\-y\fP, or \fB\-\-yes\fP, it will use only
+defaults and not prompt you for any options\.
+.SH CONFIGURATION
+.SS scope
+.RS 0
+.IP \(bu 2
+Default: none
+.IP \(bu 2
+Type: String
+
+.RE
+.P
+The scope under which the new module should be created\.
+.SH SEE ALSO
+.RS 0
+.IP \(bu 2
+https://github\.com/isaacs/init\-package\-json
+.IP \(bu 2
+npm help 5 package\.json
+.IP \(bu 2
+npm help version
+.IP \(bu 2
+npm help 7 scope
+
+.RE
+

node_modules/npm/man/man1/npm-install.1

@@ -0,0 +1,418 @@
+.TH "NPM\-INSTALL" "1" "March 2017" "" ""
+.SH "NAME"
+\fBnpm-install\fR \- Install a package
+.SH SYNOPSIS
+.P
+.RS 2
+.nf
+npm install (with no args in a package dir)
+npm install <tarball file>
+npm install <tarball url>
+npm install <folder>
+npm install [@<scope>/]<name> [\-\-save|\-\-save\-dev|\-\-save\-optional] [\-\-save\-exact] [\-\-save\-bundle]
+npm install [@<scope>/]<name>@<tag>
+npm install [@<scope>/]<name>@<version>
+npm install [@<scope>/]<name>@<version range>
+npm i (with any of the previous argument usage)
+.fi
+.RE
+.SH DESCRIPTION
+.P
+This command installs a package, and any packages that it depends on\. If the
+package has a shrinkwrap file, the installation of dependencies will be driven
+by that\. See npm help shrinkwrap\.
+.P
+A \fBpackage\fP is:
+.RS 0
+.IP \(bu 2
+a) a folder containing a program described by a npm help 5 \fBpackage\.json\fP file
+.IP \(bu 2
+b) a gzipped tarball containing (a)
+.IP \(bu 2
+c) a url that resolves to (b)
+.IP \(bu 2
+d) a \fB<name>@<version>\fP that is published on the registry (see npm help 7 \fBnpm\-registry\fP) with (c)
+.IP \(bu 2
+e) a \fB<name>@<tag>\fP (see npm help \fBnpm\-dist\-tag\fP) that points to (d)
+.IP \(bu 2
+f) a \fB<name>\fP that has a "latest" tag satisfying (e)
+.IP \(bu 2
+g) a \fB<git remote url>\fP that resolves to (b)
+
+.RE
+.P
+Even if you never publish your package, you can still get a lot of
+benefits of using npm if you just want to write a node program (a), and
+perhaps if you also want to be able to easily install it elsewhere
+after packing it up into a tarball (b)\.
+.RS 0
+.IP \(bu 2
+\fBnpm install\fP (in package directory, no arguments):
+  Install the dependencies in the local node_modules folder\.
+  In global mode (ie, with \fB\-g\fP or \fB\-\-global\fP appended to the command),
+  it installs the current package context (ie, the current working
+  directory) as a global package\.
+  By default, \fBnpm install\fP will install all modules listed as dependencies
+  in npm help 5 \fBpackage\.json\fP\|\.
+  With the \fB\-\-production\fP flag (or when the \fBNODE_ENV\fP environment variable
+  is set to \fBproduction\fP), npm will not install modules listed in
+  \fBdevDependencies\fP\|\.
+.IP \(bu 2
+\fBnpm install <folder>\fP:
+  Install a package that is sitting in a folder on the filesystem\.
+.IP \(bu 2
+\fBnpm install <tarball file>\fP:
+  Install a package that is sitting on the filesystem\.  Note: if you just want
+  to link a dev directory into your npm root, you can do this more easily by
+  using \fBnpm link\fP\|\.
+  Example:
+.P
+.RS 2
+.nf
+    npm install \./package\.tgz
+.fi
+.RE
+.IP \(bu 2
+\fBnpm install <tarball url>\fP:
+  Fetch the tarball url, and then install it\.  In order to distinguish between
+  this and other options, the argument must start with "http://" or "https://"
+  Example:
+.P
+.RS 2
+.nf
+    npm install https://github\.com/indexzero/forever/tarball/v0\.5\.6
+.fi
+.RE
+.IP \(bu 2
+\fBnpm install [@<scope>/]<name> [\-\-save|\-\-save\-dev|\-\-save\-optional]\fP:
+  Do a \fB<name>@<tag>\fP install, where \fB<tag>\fP is the "tag" config\. (See
+  npm help 7 \fBnpm\-config\fP\|\. The config's default value is \fBlatest\fP\|\.)
+  In most cases, this will install the latest version
+  of the module published on npm\.
+  Example:
+.P
+.RS 2
+.nf
+    npm install sax
+.fi
+.RE
+  \fBnpm install\fP takes 3 exclusive, optional flags which save or update
+  the package version in your main package\.json:
+.RS 0
+.IP \(bu 2
+\fB\-\-save\fP: Package will appear in your \fBdependencies\fP\|\.
+.IP \(bu 2
+\fB\-\-save\-dev\fP: Package will appear in your \fBdevDependencies\fP\|\.
+.IP \(bu 2
+\fB\-\-save\-optional\fP: Package will appear in your \fBoptionalDependencies\fP\|\.
+When using any of the above options to save dependencies to your
+package\.json, there are two additional, optional flags:
+.IP \(bu 2
+\fB\-\-save\-exact\fP: Saved dependencies will be configured with an
+exact version rather than using npm's default semver range
+operator\.
+.IP \(bu 2
+\fB\-B, \-\-save\-bundle\fP: Saved dependencies will also be added to your \fBbundleDependencies\fP list\.
+Note: if you do not include the @\-symbol on your scope name, npm will
+interpret this as a GitHub repository instead, see below\. Scopes names
+must also be followed by a slash\.
+Examples:
+.P
+.RS 2
+.nf
+npm install sax \-\-save
+npm install githubname/reponame
+npm install @myorg/privatepackage
+npm install node\-tap \-\-save\-dev
+npm install dtrace\-provider \-\-save\-optional
+npm install readable\-stream \-\-save \-\-save\-exact
+npm install ansi\-regex \-\-save \-\-save\-bundle
+.fi
+.RE
+
+.RE
+
+.RE
+.P
+.RS 2
+.nf
+**Note**: If there is a file or folder named `<name>` in the current
+working directory, then it will try to install that, and only try to
+fetch the package by name if it is not valid\.
+.fi
+.RE
+.RS 0
+.IP \(bu 2
+\fBnpm install [@<scope>/]<name>@<tag>\fP:
+  Install the version of the package that is referenced by the specified tag\.
+  If the tag does not exist in the registry data for that package, then this
+  will fail\.
+  Example:
+.P
+.RS 2
+.nf
+    npm install sax@latest
+    npm install @myorg/mypackage@latest
+.fi
+.RE
+.IP \(bu 2
+\fBnpm install [@<scope>/]<name>@<version>\fP:
+  Install the specified version of the package\.  This will fail if the
+  version has not been published to the registry\.
+  Example:
+.P
+.RS 2
+.nf
+    npm install sax@0\.1\.1
+    npm install @myorg/privatepackage@1\.5\.0
+.fi
+.RE
+.IP \(bu 2
+\fBnpm install [@<scope>/]<name>@<version range>\fP:
+  Install a version of the package matching the specified version range\.  This
+  will follow the same rules for resolving dependencies described in npm help 5 \fBpackage\.json\fP\|\.
+  Note that most version ranges must be put in quotes so that your shell will
+  treat it as a single argument\.
+  Example:
+.P
+.RS 2
+.nf
+    npm install sax@">=0\.1\.0 <0\.2\.0"
+    npm install @myorg/privatepackage@">=0\.1\.0 <0\.2\.0"
+.fi
+.RE
+.IP \(bu 2
+\fBnpm install <git remote url>\fP:
+  Install a package by cloning a git remote url\.  The format of the git
+  url is:
+.P
+.RS 2
+.nf
+    <protocol>://[<user>[:<password>]@]<hostname>[:<port>][:/]<path>[#<commit\-ish>]
+.fi
+.RE
+  \fB<protocol>\fP is one of \fBgit\fP, \fBgit+ssh\fP, \fBgit+http\fP, or
+  \fBgit+https\fP\|\.  If no \fB<commit\-ish>\fP is specified, then \fBmaster\fP is
+  used\.
+  The following git environment variables are recognized by npm and will be added
+  to the environment when running git:
+.RS 0
+.IP \(bu 2
+\fBGIT_ASKPASS\fP
+.IP \(bu 2
+\fBGIT_EXEC_PATH\fP
+.IP \(bu 2
+\fBGIT_PROXY_COMMAND\fP
+.IP \(bu 2
+\fBGIT_SSH\fP
+.IP \(bu 2
+\fBGIT_SSH_COMMAND\fP
+.IP \(bu 2
+\fBGIT_SSL_CAINFO\fP
+.IP \(bu 2
+\fBGIT_SSL_NO_VERIFY\fP
+See the git man page for details\.
+Examples:
+.P
+.RS 2
+.nf
+npm install git+ssh://git@github\.com:npm/npm\.git#v1\.0\.27
+npm install git+https://isaacs@github\.com/npm/npm\.git
+npm install git://github\.com/npm/npm\.git#v1\.0\.27
+GIT_SSH_COMMAND='ssh \-i ~/\.ssh/custom_ident' npm install git+ssh://git@github\.com:npm/npm\.git
+.fi
+.RE
+
+.RE
+.IP \(bu 2
+\fBnpm install <githubname>/<githubrepo>[#<commit\-ish>]\fP:
+.IP \(bu 2
+\fBnpm install github:<githubname>/<githubrepo>[#<commit\-ish>]\fP:
+  Install the package at \fBhttps://github\.com/githubname/githubrepo\fP by
+  attempting to clone it using \fBgit\fP\|\.
+  If you don't specify a \fIcommit\-ish\fR then \fBmaster\fP will be used\.
+  Examples:
+.P
+.RS 2
+.nf
+    npm install mygithubuser/myproject
+    npm install github:mygithubuser/myproject
+.fi
+.RE
+.IP \(bu 2
+\fBnpm install gist:[<githubname>/]<gistID>[#<commit\-ish>]\fP:
+  Install the package at \fBhttps://gist\.github\.com/gistID\fP by attempting to
+  clone it using \fBgit\fP\|\. The GitHub username associated with the gist is
+  optional and will not be saved in \fBpackage\.json\fP if \fB\-\-save\fP is used\.
+  If you don't specify a \fIcommit\-ish\fR then \fBmaster\fP will be used\.
+  Example:
+.P
+.RS 2
+.nf
+    npm install gist:101a11beef
+.fi
+.RE
+.IP \(bu 2
+\fBnpm install bitbucket:<bitbucketname>/<bitbucketrepo>[#<commit\-ish>]\fP:
+  Install the package at \fBhttps://bitbucket\.org/bitbucketname/bitbucketrepo\fP
+  by attempting to clone it using \fBgit\fP\|\.
+  If you don't specify a \fIcommit\-ish\fR then \fBmaster\fP will be used\.
+  Example:
+.P
+.RS 2
+.nf
+    npm install bitbucket:mybitbucketuser/myproject
+.fi
+.RE
+.IP \(bu 2
+\fBnpm install gitlab:<gitlabname>/<gitlabrepo>[#<commit\-ish>]\fP:
+  Install the package at \fBhttps://gitlab\.com/gitlabname/gitlabrepo\fP
+  by attempting to clone it using \fBgit\fP\|\.
+  If you don't specify a \fIcommit\-ish\fR then \fBmaster\fP will be used\.
+  Example:
+.P
+.RS 2
+.nf
+    npm install gitlab:mygitlabuser/myproject
+.fi
+.RE
+
+.RE
+.P
+You may combine multiple arguments, and even multiple types of arguments\.
+For example:
+.P
+.RS 2
+.nf
+npm install sax@">=0\.1\.0 <0\.2\.0" bench supervisor
+.fi
+.RE
+.P
+The \fB\-\-tag\fP argument will apply to all of the specified install targets\. If a
+tag with the given name exists, the tagged version is preferred over newer
+versions\.
+.P
+The \fB\-\-force\fP argument will force npm to fetch remote resources even if a
+local copy exists on disk\.
+.P
+.RS 2
+.nf
+npm install sax \-\-force
+.fi
+.RE
+.P
+The \fB\-\-global\fP argument will cause npm to install the package globally
+rather than locally\.  See npm help 5 \fBnpm\-folders\fP\|\.
+.P
+The \fB\-\-ignore\-scripts\fP argument will cause npm to not execute any
+scripts defined in the package\.json\. See npm help 7 \fBnpm\-scripts\fP\|\.
+.P
+The \fB\-\-link\fP argument will cause npm to link global installs into the
+local space in some cases\.
+.P
+The \fB\-\-no\-bin\-links\fP argument will prevent npm from creating symlinks for
+any binaries the package might contain\.
+.P
+The \fB\-\-no\-optional\fP argument will prevent optional dependencies from
+being installed\.
+.P
+The \fB\-\-no\-shrinkwrap\fP argument, which will ignore an available
+shrinkwrap file and use the package\.json instead\.
+.P
+The \fB\-\-nodedir=/path/to/node/source\fP argument will allow npm to find the
+node source code so that npm can compile native modules\.
+.P
+See npm help 7 \fBnpm\-config\fP\|\.  Many of the configuration params have some
+effect on installation, since that's most of what npm does\.
+.SH ALGORITHM
+.P
+To install a package, npm uses the following algorithm:
+.P
+.RS 2
+.nf
+install(where, what, family, ancestors)
+fetch what, unpack to <where>/node_modules/<what>
+for each dep in what\.dependencies
+  resolve dep to precise version
+for each dep@version in what\.dependencies
+    not in <where>/node_modules/<what>/node_modules/*
+    and not in <family>
+  add precise version deps to <family>
+  install(<where>/node_modules/<what>, dep, family)
+.fi
+.RE
+.P
+For this \fBpackage{dep}\fP structure: \fBA{B,C}, B{C}, C{D}\fP,
+this algorithm produces:
+.P
+.RS 2
+.nf
+A
++\-\- B
+`\-\- C
+    `\-\- D
+.fi
+.RE
+.P
+That is, the dependency from B to C is satisfied by the fact that A
+already caused C to be installed at a higher level\.
+.P
+See npm help 5 folders for a more detailed description of the specific
+folder structures that npm creates\.
+.SS Limitations of npm's Install Algorithm
+.P
+There are some very rare and pathological edge\-cases where a cycle can
+cause npm to try to install a never\-ending tree of packages\.  Here is
+the simplest case:
+.P
+.RS 2
+.nf
+A \-> B \-> A' \-> B' \-> A \-> B \-> A' \-> B' \-> A \-> \.\.\.
+.fi
+.RE
+.P
+where \fBA\fP is some version of a package, and \fBA'\fP is a different version
+of the same package\.  Because \fBB\fP depends on a different version of \fBA\fP
+than the one that is already in the tree, it must install a separate
+copy\.  The same is true of \fBA'\fP, which must install \fBB'\fP\|\.  Because \fBB'\fP
+depends on the original version of \fBA\fP, which has been overridden, the
+cycle falls into infinite regress\.
+.P
+To avoid this situation, npm flat\-out refuses to install any
+\fBname@version\fP that is already present anywhere in the tree of package
+folder ancestors\.  A more correct, but more complex, solution would be
+to symlink the existing version into the new location\.  If this ever
+affects a real use\-case, it will be investigated\.
+.SH SEE ALSO
+.RS 0
+.IP \(bu 2
+npm help 5 folders
+.IP \(bu 2
+npm help update
+.IP \(bu 2
+npm help link
+.IP \(bu 2
+npm help rebuild
+.IP \(bu 2
+npm help 7 scripts
+.IP \(bu 2
+npm help build
+.IP \(bu 2
+npm help config
+.IP \(bu 2
+npm help 7 config
+.IP \(bu 2
+npm help 5 npmrc
+.IP \(bu 2
+npm help 7 registry
+.IP \(bu 2
+npm help tag
+.IP \(bu 2
+npm help uninstall
+.IP \(bu 2
+npm help shrinkwrap
+.IP \(bu 2
+npm help 5 package\.json
+
+.RE
+

node_modules/npm/man/man1/npm-link.1

@@ -0,0 +1,103 @@
+.TH "NPM\-LINK" "1" "March 2017" "" ""
+.SH "NAME"
+\fBnpm-link\fR \- Symlink a package folder
+.SH SYNOPSIS
+.P
+.RS 2
+.nf
+npm link (in package folder)
+npm link [@<scope>/]<pkgname>
+npm ln (with any of the previous argument usage)
+.fi
+.RE
+.SH DESCRIPTION
+.P
+Package linking is a two\-step process\.
+.P
+First, \fBnpm link\fP in a package folder will create a symlink in the global folder
+\fB{prefix}/lib/node_modules/<package>\fP that links to the package where the \fBnpm
+link\fP command was executed\. (see npm help 7 \fBnpm\-config\fP for the value of \fBprefix\fP)\. It
+will also link any bins in the package to \fB{prefix}/bin/{name}\fP\|\.
+.P
+Next, in some other location, \fBnpm link package\-name\fP will create a
+symbolic link from globally\-installed \fBpackage\-name\fP to \fBnode_modules/\fP
+of the current folder\.
+.P
+Note that \fBpackage\-name\fP is taken from \fBpackage\.json\fP,
+not from directory name\.
+.P
+The package name can be optionally prefixed with a scope\. See npm help 7 \fBnpm\-scope\fP\|\.
+The scope must be preceded by an @\-symbol and followed by a slash\.
+.P
+When creating tarballs for \fBnpm publish\fP, the linked packages are
+"snapshotted" to their current state by resolving the symbolic links\.
+.P
+This is handy for installing your own stuff, so that you can work on it and
+test it iteratively without having to continually rebuild\.
+.P
+For example:
+.P
+.RS 2
+.nf
+cd ~/projects/node\-redis    # go into the package directory
+npm link                    # creates global link
+cd ~/projects/node\-bloggy   # go into some other package directory\.
+npm link redis              # link\-install the package
+.fi
+.RE
+.P
+Now, any changes to ~/projects/node\-redis will be reflected in
+~/projects/node\-bloggy/node_modules/node\-redis/\. Note that the link should
+be to the package name, not the directory name for that package\.
+.P
+You may also shortcut the two steps in one\.  For example, to do the
+above use\-case in a shorter way:
+.P
+.RS 2
+.nf
+cd ~/projects/node\-bloggy  # go into the dir of your main project
+npm link \.\./node\-redis     # link the dir of your dependency
+.fi
+.RE
+.P
+The second line is the equivalent of doing:
+.P
+.RS 2
+.nf
+(cd \.\./node\-redis; npm link)
+npm link node\-redis
+.fi
+.RE
+.P
+That is, it first creates a global link, and then links the global
+installation target into your project's \fBnode_modules\fP folder\.
+.P
+If your linked package is scoped (see npm help 7 \fBnpm\-scope\fP) your link command must
+include that scope, e\.g\.
+.P
+.RS 2
+.nf
+npm link @myorg/privatepackage
+.fi
+.RE
+.SH SEE ALSO
+.RS 0
+.IP \(bu 2
+npm help 7 developers
+.IP \(bu 2
+npm help 7 faq
+.IP \(bu 2
+npm help 5 package\.json
+.IP \(bu 2
+npm help install
+.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 npmrc
+
+.RE
+

node_modules/npm/man/man1/npm-logout.1

@@ -0,0 +1,57 @@
+.TH "NPM\-LOGOUT" "1" "March 2017" "" ""
+.SH "NAME"
+\fBnpm-logout\fR \- Log out of the registry
+.SH SYNOPSIS
+.P
+.RS 2
+.nf
+npm logout [\-\-registry=url] [\-\-scope=@orgname]
+.fi
+.RE
+.SH DESCRIPTION
+.P
+When logged into a registry that supports token\-based authentication, tell the
+server to end this token's session\. This will invalidate the token everywhere
+you're using it, not just for the current environment\.
+.P
+When logged into a legacy registry that uses username and password authentication, this will
+clear the credentials in your user configuration\. In this case, it will \fIonly\fR affect
+the current environment\.
+.P
+If \fB\-\-scope\fP is provided, this will find the credentials for the registry
+connected to that scope, if set\.
+.SH CONFIGURATION
+.SS registry
+.P
+Default: https://registry\.npmjs\.org/
+.P
+The base URL of the npm package registry\. If \fBscope\fP is also specified,
+it takes precedence\.
+.SS scope
+.P
+Default: none
+.P
+If specified, you will be logged out of the specified scope\. See npm help 7 \fBnpm\-scope\fP\|\.
+.P
+.RS 2
+.nf
+npm logout \-\-scope=@myco
+.fi
+.RE
+.SH SEE ALSO
+.RS 0
+.IP \(bu 2
+npm help adduser
+.IP \(bu 2
+npm help 7 registry
+.IP \(bu 2
+npm help config
+.IP \(bu 2
+npm help 7 config
+.IP \(bu 2
+npm help 5 npmrc
+.IP \(bu 2
+npm help whoami
+
+.RE
+

node_modules/npm/man/man1/npm-ls.1

@@ -0,0 +1,131 @@
+.TH "NPM\-LS" "1" "March 2017" "" ""
+.SH "NAME"
+\fBnpm-ls\fR \- List installed packages
+.SH SYNOPSIS
+.P
+.RS 2
+.nf
+npm list [[@<scope>/]<pkg> \.\.\.]
+npm ls [[@<scope>/]<pkg> \.\.\.]
+npm la [[@<scope>/]<pkg> \.\.\.]
+npm ll [[@<scope>/]<pkg> \.\.\.]
+.fi
+.RE
+.SH DESCRIPTION
+.P
+This command will print to stdout all the versions of packages that are
+installed, as well as their dependencies, in a tree\-structure\.
+.P
+Positional arguments are \fBname@version\-range\fP identifiers, which will
+limit the results to only the paths to the packages named\.  Note that
+nested packages will \fIalso\fR show the paths to the specified packages\.
+For example, running \fBnpm ls promzard\fP in npm's source tree will show:
+.P
+.RS 2
+.nf
+npm@2.15.12 /path/to/npm
+└─┬ init\-package\-json@0\.0\.4
+  └── promzard@0\.1\.5
+.fi
+.RE
+.P
+It will print out extraneous, missing, and invalid packages\.
+.P
+If a project specifies git urls for dependencies these are shown
+in parentheses after the name@version to make it easier for users to
+recognize potential forks of a project\.
+.P
+When run as \fBll\fP or \fBla\fP, it shows extended information by default\.
+.SH CONFIGURATION
+.SS json
+.RS 0
+.IP \(bu 2
+Default: false
+.IP \(bu 2
+Type: Boolean
+
+.RE
+.P
+Show information in JSON format\.
+.SS long
+.RS 0
+.IP \(bu 2
+Default: false
+.IP \(bu 2
+Type: Boolean
+
+.RE
+.P
+Show extended information\.
+.SS parseable
+.RS 0
+.IP \(bu 2
+Default: false
+.IP \(bu 2
+Type: Boolean
+
+.RE
+.P
+Show parseable output instead of tree view\.
+.SS global
+.RS 0
+.IP \(bu 2
+Default: false
+.IP \(bu 2
+Type: Boolean
+
+.RE
+.P
+List packages in the global install prefix instead of in the current
+project\.
+.SS depth
+.RS 0
+.IP \(bu 2
+Type: Int
+
+.RE
+.P
+Max display depth of the dependency tree\.
+.SS prod / production
+.RS 0
+.IP \(bu 2
+Type: Boolean
+.IP \(bu 2
+Default: false
+
+.RE
+.P
+Display only the dependency tree for packages in \fBdependencies\fP\|\.
+.SS dev
+.RS 0
+.IP \(bu 2
+Type: Boolean
+.IP \(bu 2
+Default: false
+
+.RE
+.P
+Display only the dependency tree for packages in \fBdevDependencies\fP\|\.
+.SH SEE ALSO
+.RS 0
+.IP \(bu 2
+npm help config
+.IP \(bu 2
+npm help 7 config
+.IP \(bu 2
+npm help 5 npmrc
+.IP \(bu 2
+npm help 5 folders
+.IP \(bu 2
+npm help install
+.IP \(bu 2
+npm help link
+.IP \(bu 2
+npm help prune
+.IP \(bu 2
+npm help outdated
+.IP \(bu 2
+npm help update
+
+.RE
+

node_modules/npm/man/man1/npm-outdated.1

@@ -0,0 +1,151 @@
+.TH "NPM\-OUTDATED" "1" "March 2017" "" ""
+.SH "NAME"
+\fBnpm-outdated\fR \- Check for outdated packages
+.SH SYNOPSIS
+.P
+.RS 2
+.nf
+npm outdated [<name> [<name> \.\.\.]]
+.fi
+.RE
+.SH DESCRIPTION
+.P
+This command will check the registry to see if any (or, specific) installed
+packages are currently outdated\.
+.P
+In the output:
+.RS 0
+.IP \(bu 2
+\fBwanted\fP is the maximum version of the package that satisfies the semver
+range specified in \fBpackage\.json\fP\|\. If there's no available semver range (i\.e\.
+you're running \fBnpm outdated \-\-global\fP, or the package isn't included in
+\fBpackage\.json\fP), then \fBwanted\fP shows the currently\-installed version\.
+.IP \(bu 2
+\fBlatest\fP is the version of the package tagged as latest in the registry\.
+Running \fBnpm publish\fP with no special configuration will publish the package
+with a dist\-tag of \fBlatest\fP\|\. This may or may not be the maximum version of
+the package, or the most\-recently published version of the package, depending
+on how the package's developer manages the latest npm help dist\-tag\.
+.IP \(bu 2
+\fBlocation\fP is where in the dependency tree the package is located\. Note that
+\fBnpm outdated\fP defaults to a depth of 0, so unless you override that, you'll
+always be seeing only top\-level dependencies that are outdated\.
+.IP \(bu 2
+\fBpackage type\fP (when using \fB\-\-long\fP / \fB\-l\fP) tells you whether this package is
+a \fBdependency\fP or a \fBdevDependency\fP\|\. Packages not included in \fBpackage\.json\fP
+are always marked \fBdependencies\fP\|\.
+
+.RE
+.SS An example
+.P
+.RS 2
+.nf
+$ npm outdated
+Package      Current   Wanted   Latest  Location
+glob          5\.0\.15   5\.0\.15    6\.0\.1  test\-outdated\-output
+nothingness    0\.0\.3      git      git  test\-outdated\-output
+npm            3\.5\.1    3\.5\.2    3\.5\.1  test\-outdated\-output
+local\-dev      0\.0\.3   linked   linked  test\-outdated\-output
+once           1\.3\.2    1\.3\.3    1\.3\.3  test\-outdated\-output
+.fi
+.RE
+.P
+With these \fBdependencies\fP:
+.P
+.RS 2
+.nf
+{
+  "glob": "^5\.0\.15",
+  "nothingness": "github:othiym23/nothingness#master",
+  "npm": "^3\.5\.1",
+  "once": "^1\.3\.1"
+}
+.fi
+.RE
+.P
+A few things to note:
+.RS 0
+.IP \(bu 2
+\fBglob\fP requires \fB^5\fP, which prevents npm from installing \fBglob@6\fP, which is
+outside the semver range\.
+.IP \(bu 2
+Git dependencies will always be reinstalled, because of how they're specified\.
+The installed committish might satisfy the dependency specifier (if it's
+something immutable, like a commit SHA), or it might not, so \fBnpm outdated\fP and
+\fBnpm update\fP have to fetch Git repos to check\. This is why currently doing a
+reinstall of a Git dependency always forces a new clone and install\.
+.IP \(bu 2
+\fBnpm@3\.5\.2\fP is marked as "wanted", but "latest" is \fBnpm@3\.5\.1\fP because npm
+uses dist\-tags to manage its \fBlatest\fP and \fBnext\fP release channels\. \fBnpm update\fP
+will install the \fInewest\fR version, but \fBnpm install npm\fP (with no semver range)
+will install whatever's tagged as \fBlatest\fP\|\.
+.IP \(bu 2
+\fBonce\fP is just plain out of date\. Reinstalling \fBnode_modules\fP from scratch or
+running \fBnpm update\fP will bring it up to spec\.
+
+.RE
+.SH CONFIGURATION
+.SS json
+.RS 0
+.IP \(bu 2
+Default: false
+.IP \(bu 2
+Type: Boolean
+
+.RE
+.P
+Show information in JSON format\.
+.SS long
+.RS 0
+.IP \(bu 2
+Default: false
+.IP \(bu 2
+Type: Boolean
+
+.RE
+.P
+Show extended information\.
+.SS parseable
+.RS 0
+.IP \(bu 2
+Default: false
+.IP \(bu 2
+Type: Boolean
+
+.RE
+.P
+Show parseable output instead of tree view\.
+.SS global
+.RS 0
+.IP \(bu 2
+Default: false
+.IP \(bu 2
+Type: Boolean
+
+.RE
+.P
+Check packages in the global install prefix instead of in the current
+project\.
+.SS depth
+.RS 0
+.IP \(bu 2
+Default: 0
+.IP \(bu 2
+Type: Int
+
+.RE
+.P
+Max depth for checking dependency tree\.
+.SH SEE ALSO
+.RS 0
+.IP \(bu 2
+npm help update
+.IP \(bu 2
+npm help dist\-tag
+.IP \(bu 2
+npm help 7 registry
+.IP \(bu 2
+npm help 5 folders
+
+.RE
+

node_modules/npm/man/man1/npm-owner.1

@@ -0,0 +1,49 @@
+.TH "NPM\-OWNER" "1" "March 2017" "" ""
+.SH "NAME"
+\fBnpm-owner\fR \- Manage package owners
+.SH SYNOPSIS
+.P
+.RS 2
+.nf
+npm owner ls <package name>
+npm owner add <user> <package name>
+npm owner rm <user> <package name>
+
+aliases: author
+.fi
+.RE
+.SH DESCRIPTION
+.P
+Manage ownership of published packages\.
+.RS 0
+.IP \(bu 2
+ls:
+List all the users who have access to modify a package and push new versions\.
+Handy when you need to know who to bug for help\.
+.IP \(bu 2
+add:
+Add a new user as a maintainer of a package\.  This user is enabled to modify
+metadata, publish new versions, and add other owners\.
+.IP \(bu 2
+rm:
+Remove a user from the package owner list\.  This immediately revokes their
+privileges\.
+
+.RE
+.P
+Note that there is only one level of access\.  Either you can modify a package,
+or you can't\.  Future versions may contain more fine\-grained access levels, but
+that is not implemented at this time\.
+.SH SEE ALSO
+.RS 0
+.IP \(bu 2
+npm help publish
+.IP \(bu 2
+npm help 7 registry
+.IP \(bu 2
+npm help adduser
+.IP \(bu 2
+npm help 7 disputes
+
+.RE
+

node_modules/npm/man/man1/npm-pack.1

@@ -0,0 +1,37 @@
+.TH "NPM\-PACK" "1" "March 2017" "" ""
+.SH "NAME"
+\fBnpm-pack\fR \- Create a tarball from a package
+.SH SYNOPSIS
+.P
+.RS 2
+.nf
+npm pack [<pkg> [<pkg> \.\.\.]]
+.fi
+.RE
+.SH DESCRIPTION
+.P
+For anything that's installable (that is, a package folder, tarball,
+tarball url, name@tag, name@version, or name), this command will fetch
+it to the cache, and then copy the tarball to the current working
+directory as \fB<name>\-<version>\.tgz\fP, and then write the filenames out to
+stdout\.
+.P
+If the same package is specified multiple times, then the file will be
+overwritten the second time\.
+.P
+If no arguments are supplied, then npm packs the current package folder\.
+.SH SEE ALSO
+.RS 0
+.IP \(bu 2
+npm help cache
+.IP \(bu 2
+npm help publish
+.IP \(bu 2
+npm help config
+.IP \(bu 2
+npm help 7 config
+.IP \(bu 2
+npm help 5 npmrc
+
+.RE
+

node_modules/npm/man/man1/npm-ping.1

@@ -0,0 +1,24 @@
+.TH "NPM\-PING" "1" "March 2017" "" ""
+.SH "NAME"
+\fBnpm-ping\fR \- Ping npm registry
+.SH SYNOPSIS
+.P
+.RS 2
+.nf
+npm ping [\-\-registry <registry>]
+.fi
+.RE
+.SH DESCRIPTION
+.P
+Ping the configured or given npm registry and verify authentication\.
+.SH SEE ALSO
+.RS 0
+.IP \(bu 2
+npm help config
+.IP \(bu 2
+npm help 7 config
+.IP \(bu 2
+npm help 5 npmrc
+
+.RE
+

node_modules/npm/man/man1/npm-prefix.1

@@ -0,0 +1,34 @@
+.TH "NPM\-PREFIX" "1" "March 2017" "" ""
+.SH "NAME"
+\fBnpm-prefix\fR \- Display prefix
+.SH SYNOPSIS
+.P
+.RS 2
+.nf
+npm prefix [\-g]
+.fi
+.RE
+.SH DESCRIPTION
+.P
+Print the local prefix to standard out\. This is the closest parent directory
+to contain a package\.json file unless \fB\-g\fP is also specified\.
+.P
+If \fB\-g\fP is specified, this will be the value of the global prefix\. See
+npm help 7 \fBnpm\-config\fP for more detail\.
+.SH SEE ALSO
+.RS 0
+.IP \(bu 2
+npm help root
+.IP \(bu 2
+npm help bin
+.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 npmrc
+
+.RE
+

node_modules/npm/man/man1/npm-prune.1

@@ -0,0 +1,35 @@
+.TH "NPM\-PRUNE" "1" "March 2017" "" ""
+.SH "NAME"
+\fBnpm-prune\fR \- Remove extraneous packages
+.SH SYNOPSIS
+.P
+.RS 2
+.nf
+npm prune [<name> [<name \.\.\.]]
+npm prune [<name> [<name \.\.\.]] [\-\-production]
+.fi
+.RE
+.SH DESCRIPTION
+.P
+This command removes "extraneous" packages\.  If a package name is
+provided, then only packages matching one of the supplied names are
+removed\.
+.P
+Extraneous packages are packages that are not listed on the parent
+package's dependencies list\.
+.P
+If the \fB\-\-production\fP flag is specified or the \fBNODE_ENV\fP environment
+variable is set to \fBproduction\fP, this command will remove the packages
+specified in your \fBdevDependencies\fP\|\. Setting \fB\-\-production=false\fP will
+negate \fBNODE_ENV\fP being set to \fBproduction\fP\|\.
+.SH SEE ALSO
+.RS 0
+.IP \(bu 2
+npm help uninstall
+.IP \(bu 2
+npm help 5 folders
+.IP \(bu 2
+npm help ls
+
+.RE
+

node_modules/npm/man/man1/npm-publish.1

@@ -0,0 +1,68 @@
+.TH "NPM\-PUBLISH" "1" "March 2017" "" ""
+.SH "NAME"
+\fBnpm-publish\fR \- Publish a package
+.SH SYNOPSIS
+.P
+.RS 2
+.nf
+npm publish <tarball> [\-\-tag <tag>] [\-\-access <public|restricted>]
+npm publish <folder> [\-\-tag <tag>] [\-\-access <public|restricted>]
+.fi
+.RE
+.SH DESCRIPTION
+.P
+Publishes a package to the registry so that it can be installed by name\. All
+files in the package directory are included if no local \fB\|\.gitignore\fP or
+\fB\|\.npmignore\fP file is present\. See npm help 7 \fBnpm\-developers\fP for full details on
+what's included in the published package, as well as details on how the package
+is built\.
+.P
+By default npm will publish to the public registry\. This can be overridden by
+specifying a different default registry or using a npm help 7 \fBnpm\-scope\fP in the name
+(see npm help 5 \fBpackage\.json\fP)\.
+.RS 0
+.IP \(bu 2
+\fB<folder>\fP:
+A folder containing a package\.json file
+.IP \(bu 2
+\fB<tarball>\fP:
+A url or file path to a gzipped tar archive containing a single folder
+with a package\.json file inside\.
+.IP \(bu 2
+\fB[\-\-tag <tag>]\fP
+Registers the published package with the given tag, such that \fBnpm install
+<name>@<tag>\fP will install this version\.  By default, \fBnpm publish\fP updates
+and \fBnpm install\fP installs the \fBlatest\fP tag\. See npm help \fBnpm\-dist\-tag\fP for
+details about tags\.
+.IP \(bu 2
+\fB[\-\-access <public|restricted>]\fP
+Tells the registry whether this package should be published as public or
+restricted\. Only applies to scoped packages, which default to \fBrestricted\fP\|\.
+If you don't have a paid account, you must publish with \fB\-\-access public\fP
+to publish scoped packages\.
+
+.RE
+.P
+Fails if the package name and version combination already exists in
+the specified registry\.
+.P
+Once a package is published with a given name and version, that
+specific name and version combination can never be used again, even if
+it is removed with npm help unpublish\.
+.SH SEE ALSO
+.RS 0
+.IP \(bu 2
+npm help 7 registry
+.IP \(bu 2
+npm help 7 scope
+.IP \(bu 2
+npm help adduser
+.IP \(bu 2
+npm help owner
+.IP \(bu 2
+npm help deprecate
+.IP \(bu 2
+npm help tag
+
+.RE
+

node_modules/npm/man/man1/npm-rebuild.1

@@ -0,0 +1,31 @@
+.TH "NPM\-REBUILD" "1" "March 2017" "" ""
+.SH "NAME"
+\fBnpm-rebuild\fR \- Rebuild a package
+.SH SYNOPSIS
+.P
+.RS 2
+.nf
+npm rebuild [<name> [<name> \.\.\.]]
+npm rb [<name> [<name> \.\.\.]]
+.fi
+.RE
+.RS 0
+.IP \(bu 2
+\fB<name>\fP:
+The package to rebuild
+
+.RE
+.SH DESCRIPTION
+.P
+This command runs the \fBnpm build\fP command on the matched folders\.  This is useful
+when you install a new version of node, and must recompile all your C++ addons with
+the new binary\.
+.SH SEE ALSO
+.RS 0
+.IP \(bu 2
+npm help build
+.IP \(bu 2
+npm help install
+
+.RE
+

node_modules/npm/man/man1/npm-repo.1

@@ -0,0 +1,37 @@
+.TH "NPM\-REPO" "1" "March 2017" "" ""
+.SH "NAME"
+\fBnpm-repo\fR \- Open package repository page in the browser
+.SH SYNOPSIS
+.P
+.RS 2
+.nf
+npm repo <pkgname>
+npm repo (with no args in a package dir)
+.fi
+.RE
+.SH DESCRIPTION
+.P
+This command tries to guess at the likely location of a package's
+repository URL, and then tries to open it using the \fB\-\-browser\fP
+config param\. If no package name is provided, it will search for
+a \fBpackage\.json\fP in the current folder and use the \fBname\fP property\.
+.SH CONFIGURATION
+.SS browser
+.RS 0
+.IP \(bu 2
+Default: OS X: \fB"open"\fP, Windows: \fB"start"\fP, Others: \fB"xdg\-open"\fP
+.IP \(bu 2
+Type: String
+
+.RE
+.P
+The browser that is called by the \fBnpm repo\fP command to open websites\.
+.SH SEE ALSO
+.RS 0
+.IP \(bu 2
+npm help docs
+.IP \(bu 2
+npm help config
+
+.RE
+

node_modules/npm/man/man1/npm-restart.1

@@ -0,0 +1,61 @@
+.TH "NPM\-RESTART" "1" "March 2017" "" ""
+.SH "NAME"
+\fBnpm-restart\fR \- Restart a package
+.SH SYNOPSIS
+.P
+.RS 2
+.nf
+npm restart [\-\- <args>]
+.fi
+.RE
+.SH DESCRIPTION
+.P
+This restarts a package\.
+.P
+This runs a package's "stop", "restart", and "start" scripts, and associated
+pre\- and post\- scripts, in the order given below:
+.RS 0
+.IP 1. 3
+prerestart
+.IP 2. 3
+prestop
+.IP 3. 3
+stop
+.IP 4. 3
+poststop
+.IP 5. 3
+restart
+.IP 6. 3
+prestart
+.IP 7. 3
+start
+.IP 8. 3
+poststart
+.IP 9. 3
+postrestart
+
+.RE
+.SH NOTE
+.P
+Note that the "restart" script is run \fBin addition to\fR the "stop"
+and "start" scripts, not instead of them\.
+.P
+This is the behavior as of \fBnpm\fP major version 2\.  A change in this
+behavior will be accompanied by an increase in major version number
+.SH SEE ALSO
+.RS 0
+.IP \(bu 2
+npm help run\-script
+.IP \(bu 2
+npm help 7 scripts
+.IP \(bu 2
+npm help test
+.IP \(bu 2
+npm help start
+.IP \(bu 2
+npm help stop
+.IP \(bu 2
+npm apihelp restart
+
+.RE
+

node_modules/npm/man/man1/npm-rm.1

@@ -0,0 +1,34 @@
+.TH "NPM\-RM" "1" "March 2017" "" ""
+.SH "NAME"
+\fBnpm-rm\fR \- Remove a package
+.SH SYNOPSIS
+.P
+.RS 2
+.nf
+npm rm <name>
+npm r <name>
+npm uninstall <name>
+npm un <name>
+.fi
+.RE
+.SH DESCRIPTION
+.P
+This uninstalls a package, completely removing everything npm installed
+on its behalf\.
+.SH SEE ALSO
+.RS 0
+.IP \(bu 2
+npm help prune
+.IP \(bu 2
+npm help install
+.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 npmrc
+
+.RE
+

node_modules/npm/man/man1/npm-root.1

@@ -0,0 +1,30 @@
+.TH "NPM\-ROOT" "1" "March 2017" "" ""
+.SH "NAME"
+\fBnpm-root\fR \- Display npm root
+.SH SYNOPSIS
+.P
+.RS 2
+.nf
+npm root
+.fi
+.RE
+.SH DESCRIPTION
+.P
+Print the effective \fBnode_modules\fP folder to standard out\.
+.SH SEE ALSO
+.RS 0
+.IP \(bu 2
+npm help prefix
+.IP \(bu 2
+npm help bin
+.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 npmrc
+
+.RE
+

node_modules/npm/man/man1/npm-run-script.1

@@ -0,0 +1,66 @@
+.TH "NPM\-RUN\-SCRIPT" "1" "March 2017" "" ""
+.SH "NAME"
+\fBnpm-run-script\fR \- Run arbitrary package scripts
+.SH SYNOPSIS
+.P
+.RS 2
+.nf
+npm run\-script [command] [\-\- <args>]
+npm run [command] [\-\- <args>]
+.fi
+.RE
+.SH DESCRIPTION
+.P
+This runs an arbitrary command from a package's \fB"scripts"\fP object\.  If no
+\fB"command"\fP is provided, it will list the available scripts\.  \fBrun[\-script]\fP is
+used by the test, start, restart, and stop commands, but can be called
+directly, as well\. When the scripts in the package are printed out, they're
+separated into lifecycle (test, start, restart) and directly\-run scripts\.
+.P
+As of \fBnpm@2\.0\.0\fP \fIhttp://blog\.npmjs\.org/post/98131109725/npm\-2\-0\-0\fR, you can
+use custom arguments when executing scripts\. The special option \fB\-\-\fP is used by
+getopt \fIhttp://goo\.gl/KxMmtG\fR to delimit the end of the options\. npm will pass
+all the arguments after the \fB\-\-\fP directly to your script:
+.P
+.RS 2
+.nf
+npm run test \-\- \-\-grep="pattern"
+.fi
+.RE
+.P
+The arguments will only be passed to the script specified after \fBnpm run\fP
+and not to any pre or post script\.
+.P
+The \fBenv\fP script is a special built\-in command that can be used to list
+environment variables that will be available to the script at runtime\. If an
+"env" command is defined in your package it will take precedence over the
+built\-in\.
+.P
+In addition to the shell's pre\-existing \fBPATH\fP, \fBnpm run\fP adds
+\fBnode_modules/\.bin\fP to the \fBPATH\fP provided to scripts\. Any binaries provided by
+locally\-installed dependencies can be used without the \fBnode_modules/\.bin\fP
+prefix\. For example, if there is a \fBdevDependency\fP on \fBtap\fP in your package,
+you should write:
+.P
+.RS 2
+.nf
+"scripts": {"test": "tap test/\\*\.js"}
+.fi
+.RE
+.P
+instead of \fB"scripts": {"test": "node_modules/\.bin/tap test/\\*\.js"}\fP to run your tests\.
+.SH SEE ALSO
+.RS 0
+.IP \(bu 2
+npm help 7 scripts
+.IP \(bu 2
+npm help test
+.IP \(bu 2
+npm help start
+.IP \(bu 2
+npm help restart
+.IP \(bu 2
+npm help stop
+
+.RE
+

node_modules/npm/man/man1/npm-search.1

@@ -0,0 +1,60 @@
+.TH "NPM\-SEARCH" "1" "March 2017" "" ""
+.SH "NAME"
+\fBnpm-search\fR \- Search for packages
+.SH SYNOPSIS
+.P
+.RS 2
+.nf
+npm search [\-l|\-\-long] [search terms \.\.\.]
+
+aliases: s, se, find
+.fi
+.RE
+.SH DESCRIPTION
+.P
+Search the registry for packages matching the search terms\.
+.P
+If a term starts with \fB/\fP, then it's interpreted as a regular expression\.
+A trailing \fB/\fP will be ignored in this case\.  (Note that many regular
+expression characters must be escaped or quoted in most shells\.)
+.SH CONFIGURATION
+.SS long
+.RS 0
+.IP \(bu 2
+Default: false
+.IP \(bu 2
+Type: Boolean
+
+.RE
+.P
+Display full package descriptions and other long text across multiple
+lines\. When disabled (default) search results are truncated to fit
+neatly on a single line\. Modules with extremely long names will
+fall on multiple lines\.
+.SS registry
+.RS 0
+.IP \(bu 2
+Default: https://registry\.npmjs\.org/
+.IP \(bu 2
+Type   : url
+
+.RE
+.P
+Search the specified registry for modules\. If you have configured npm to point to a different default registry,
+such as your internal private module repository, \fBnpm search\fP will default to that registry when searching\.
+Pass a different registry url such as the default above in order to override this setting\.
+.SH SEE ALSO
+.RS 0
+.IP \(bu 2
+npm help 7 registry
+.IP \(bu 2
+npm help config
+.IP \(bu 2
+npm help 7 config
+.IP \(bu 2
+npm help 5 npmrc
+.IP \(bu 2
+npm help view
+
+.RE
+

node_modules/npm/man/man1/npm-shrinkwrap.1

@@ -0,0 +1,222 @@
+.TH "NPM\-SHRINKWRAP" "1" "March 2017" "" ""
+.SH "NAME"
+\fBnpm-shrinkwrap\fR \- Lock down dependency versions
+.SH SYNOPSIS
+.P
+.RS 2
+.nf
+npm shrinkwrap
+.fi
+.RE
+.SH DESCRIPTION
+.P
+This command locks down the versions of a package's dependencies so
+that you can control exactly which versions of each dependency will be
+used when your package is installed\. The \fBpackage\.json\fP file is still
+required if you want to use \fBnpm install\fP\|\.
+.P
+By default, \fBnpm install\fP recursively installs the target's
+dependencies (as specified in \fBpackage\.json\fP), choosing the latest
+available version that satisfies the dependency's semver pattern\. In
+some situations, particularly when shipping software where each change
+is tightly managed, it's desirable to fully specify each version of
+each dependency recursively so that subsequent builds and deploys do
+not inadvertently pick up newer versions of a dependency that satisfy
+the semver pattern\. Specifying specific semver patterns in each
+dependency's \fBpackage\.json\fP would facilitate this, but that's not always
+possible or desirable, as when another author owns the npm package\.
+It's also possible to check dependencies directly into source control,
+but that may be undesirable for other reasons\.
+.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 B@0\.0\.2 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 B@0\.0\.1\. However, if A's author and B's
+author are not the same person, there's no way for A's author to say
+that he or she does not want to pull in newly published versions of C
+when B hasn't changed at all\.
+.P
+In this case, A's author can run
+.P
+.RS 2
+.nf
+npm shrinkwrap
+.fi
+.RE
+.P
+This generates \fBnpm\-shrinkwrap\.json\fP, which will look something like this:
+.P
+.RS 2
+.nf
+{
+  "name": "A",
+  "version": "0\.1\.0",
+  "dependencies": {
+    "B": {
+      "version": "0\.0\.1",
+      "from": "B@^0\.0\.1",
+      "resolved": "https://registry\.npmjs\.org/B/\-/B\-0\.0\.1\.tgz",
+      "dependencies": {
+        "C": {
+          "version": "0\.0\.1",
+          "from": "org/C#v0\.0\.1",
+          "resolved": "git://github\.com/org/C\.git#5c380ae319fc4efe9e7f2d9c78b0faa588fd99b4"
+        }
+      }
+    }
+  }
+}
+.fi
+.RE
+.P
+The shrinkwrap command has locked down the dependencies based on
+what's currently installed in node_modules\.  When \fBnpm install\fP
+installs a package with an \fBnpm\-shrinkwrap\.json\fP in the package
+root, the shrinkwrap file (rather than \fBpackage\.json\fP files) completely
+drives the installation of that package and all of its dependencies
+(recursively)\.  So now the author publishes A@0\.1\.0, and subsequent
+installs of this package will use B@0\.0\.1 and C@0\.0\.1, regardless the
+dependencies and versions listed in A's, B's, and C's \fBpackage\.json\fP
+files\.
+.SS Using shrinkwrapped packages
+.P
+Using a shrinkwrapped package is no different than using any other
+package: you can \fBnpm install\fP it by hand, or add a dependency to your
+\fBpackage\.json\fP file and \fBnpm install\fP it\.
+.SS Building shrinkwrapped packages
+.P
+To shrinkwrap an existing package:
+.RS 0
+.IP 1. 3
+Run \fBnpm install\fP in the package root to install the current
+versions of all dependencies\.
+.IP 2. 3
+Validate that the package works as expected with these versions\.
+.IP 3. 3
+Run \fBnpm shrinkwrap\fP, add \fBnpm\-shrinkwrap\.json\fP to git, and publish
+your package\.
+
+.RE
+.P
+To add or update a dependency in a shrinkwrapped package:
+.RS 0
+.IP 1. 3
+Run \fBnpm install\fP in the package root to install the current
+versions of all dependencies\.
+.IP 2. 3
+Add or update dependencies\. \fBnpm install\fP each new or updated
+package individually and then update \fBpackage\.json\fP\|\.  Note that they
+must be explicitly named in order to be installed: running \fBnpm
+install\fP with no arguments will merely reproduce the existing
+shrinkwrap\.
+.IP 3. 3
+Validate that the package works as expected with the new
+dependencies\.
+.IP 4. 3
+Run \fBnpm shrinkwrap\fP, commit the new \fBnpm\-shrinkwrap\.json\fP, and
+publish your package\.
+
+.RE
+.P
+You can use npm help outdated to view dependencies with newer versions
+available\.
+.SS Other Notes
+.P
+A shrinkwrap file must be consistent with the package's \fBpackage\.json\fP
+file\. \fBnpm shrinkwrap\fP will fail if required dependencies are not
+already installed, since that would result in a shrinkwrap that
+wouldn't actually work\. Similarly, the command will fail if there are
+extraneous packages (not referenced by \fBpackage\.json\fP), since that would
+indicate that \fBpackage\.json\fP is not correct\.
+.P
+Since \fBnpm shrinkwrap\fP is intended to lock down your dependencies for
+production use, \fBdevDependencies\fP will not be included unless you
+explicitly set the \fB\-\-dev\fP flag when you run \fBnpm shrinkwrap\fP\|\.  If
+installed \fBdevDependencies\fP are excluded, then npm will print a
+warning\.  If you want them to be installed with your module by
+default, please consider adding them to \fBdependencies\fP instead\.
+.P
+If shrinkwrapped package A depends on shrinkwrapped package B, B's
+shrinkwrap will not be used as part of the installation of A\. However,
+because A's shrinkwrap is constructed from a valid installation of B
+and recursively specifies all dependencies, the contents of B's
+shrinkwrap will implicitly be included in A's shrinkwrap\.
+.SS Caveats
+.P
+If you wish to lock down the specific bytes included in a package, for
+example to have 100% confidence in being able to reproduce a
+deployment or build, then you ought to check your dependencies into
+source control, or pursue some other mechanism that can verify
+contents rather than versions\.
+.SH SEE ALSO
+.RS 0
+.IP \(bu 2
+npm help install
+.IP \(bu 2
+npm help 5 package\.json
+.IP \(bu 2
+npm help ls
+
+.RE
+

node_modules/npm/man/man1/npm-star.1

@@ -0,0 +1,30 @@
+.TH "NPM\-STAR" "1" "March 2017" "" ""
+.SH "NAME"
+\fBnpm-star\fR \- Mark your favorite packages
+.SH SYNOPSIS
+.P
+.RS 2
+.nf
+npm star <pkgname> [<pkg>, \.\.\.]
+npm unstar <pkgname> [<pkg>, \.\.\.]
+.fi
+.RE
+.SH DESCRIPTION
+.P
+"Starring" a package means that you have some interest in it\.  It's
+a vaguely positive way to show that you care\.
+.P
+"Unstarring" is the same thing, but in reverse\.
+.P
+It's a boolean thing\.  Starring repeatedly has no additional effect\.
+.SH SEE ALSO
+.RS 0
+.IP \(bu 2
+npm help view
+.IP \(bu 2
+npm help whoami
+.IP \(bu 2
+npm help adduser
+
+.RE
+

node_modules/npm/man/man1/npm-stars.1

@@ -0,0 +1,31 @@
+.TH "NPM\-STARS" "1" "March 2017" "" ""
+.SH "NAME"
+\fBnpm-stars\fR \- View packages marked as favorites
+.SH SYNOPSIS
+.P
+.RS 2
+.nf
+npm stars
+npm stars [username]
+.fi
+.RE
+.SH DESCRIPTION
+.P
+If you have starred a lot of neat things and want to find them again
+quickly this command lets you do just that\.
+.P
+You may also want to see your friend's favorite packages, in this case
+you will most certainly enjoy this command\.
+.SH SEE ALSO
+.RS 0
+.IP \(bu 2
+npm help star
+.IP \(bu 2
+npm help view
+.IP \(bu 2
+npm help whoami
+.IP \(bu 2
+npm help adduser
+
+.RE
+

node_modules/npm/man/man1/npm-start.1

@@ -0,0 +1,34 @@
+.TH "NPM\-START" "1" "March 2017" "" ""
+.SH "NAME"
+\fBnpm-start\fR \- Start a package
+.SH SYNOPSIS
+.P
+.RS 2
+.nf
+npm start [\-\- <args>]
+.fi
+.RE
+.SH DESCRIPTION
+.P
+This runs an arbitrary command specified in the package's \fB"start"\fP property of
+its \fB"scripts"\fP object\. If no \fB"start"\fP property is specified on the
+\fB"scripts"\fP object, it will run \fBnode server\.js\fP\|\.
+.P
+As of \fBnpm@2\.0\.0\fP \fIhttp://blog\.npmjs\.org/post/98131109725/npm\-2\-0\-0\fR, you can
+use custom arguments when executing scripts\. Refer to npm help run\-script for
+more details\.
+.SH SEE ALSO
+.RS 0
+.IP \(bu 2
+npm help run\-script
+.IP \(bu 2
+npm help 7 scripts
+.IP \(bu 2
+npm help test
+.IP \(bu 2
+npm help restart
+.IP \(bu 2
+npm help stop
+
+.RE
+

node_modules/npm/man/man1/npm-stop.1

@@ -0,0 +1,28 @@
+.TH "NPM\-STOP" "1" "March 2017" "" ""
+.SH "NAME"
+\fBnpm-stop\fR \- Stop a package
+.SH SYNOPSIS
+.P
+.RS 2
+.nf
+npm stop [\-\- <args>]
+.fi
+.RE
+.SH DESCRIPTION
+.P
+This runs a package's "stop" script, if one was provided\.
+.SH SEE ALSO
+.RS 0
+.IP \(bu 2
+npm help run\-script
+.IP \(bu 2
+npm help 7 scripts
+.IP \(bu 2
+npm help test
+.IP \(bu 2
+npm help start
+.IP \(bu 2
+npm help restart
+
+.RE
+

node_modules/npm/man/man1/npm-tag.1

@@ -0,0 +1,79 @@
+.TH "NPM\-TAG" "1" "March 2017" "" ""
+.SH "NAME"
+\fBnpm-tag\fR \- Tag a published version
+.SH SYNOPSIS
+.P
+.RS 2
+.nf
+npm tag <name>@<version> [<tag>]
+.fi
+.RE
+.SH DESCRIPTION
+.P
+THIS COMMAND IS DEPRECATED\. See npm help dist\-tag for details\.
+.P
+Tags the specified version of the package with the specified tag, or the
+\fB\-\-tag\fP config if not specified\.
+.P
+A tag can be used when installing packages as a reference to a version instead
+of using a specific version number:
+.P
+.RS 2
+.nf
+npm install <name>@<tag>
+.fi
+.RE
+.P
+When installing dependencies, a preferred tagged version may be specified:
+.P
+.RS 2
+.nf
+npm install \-\-tag <tag>
+.fi
+.RE
+.P
+This also applies to \fBnpm dedupe\fP\|\.
+.P
+Publishing a package always sets the "latest" tag to the published version\.
+.SH PURPOSE
+.P
+Tags can be used to provide an alias instead of version numbers\.  For
+example, \fBnpm\fP currently uses the tag "next" to identify the upcoming
+version, and the tag "latest" to identify the current version\.
+.P
+A project might choose to have multiple streams of development, e\.g\.,
+"stable", "canary"\.
+.SH CAVEATS
+.P
+Tags must share a namespace with version numbers, because they are
+specified in the same slot: \fBnpm install <pkg>@<version>\fP vs \fBnpm
+install <pkg>@<tag>\fP\|\.
+.P
+Tags that can be interpreted as valid semver ranges will be
+rejected\. For example, \fBv1\.4\fP cannot be used as a tag, because it is
+interpreted by semver as \fB>=1\.4\.0 <1\.5\.0\fP\|\.  See
+https://github\.com/npm/npm/issues/6082\|\.
+.P
+The simplest way to avoid semver problems with tags is to use tags
+that do not begin with a number or the letter \fBv\fP\|\.
+.SH SEE ALSO
+.RS 0
+.IP \(bu 2
+npm help publish
+.IP \(bu 2
+npm help install
+.IP \(bu 2
+npm help dedupe
+.IP \(bu 2
+npm help 7 registry
+.IP \(bu 2
+npm help config
+.IP \(bu 2
+npm help 7 config
+.IP \(bu 2
+npm help dist\-tag
+.IP \(bu 2
+npm help 5 npmrc
+
+.RE
+

node_modules/npm/man/man1/npm-team.1

@@ -0,0 +1,64 @@
+.TH "NPM\-TEAM" "1" "March 2017" "" ""
+.SH "NAME"
+\fBnpm-team\fR \- Manage organization teams and team memberships
+.SH SYNOPSIS
+.P
+.RS 2
+.nf
+npm team create <scope:team>
+npm team destroy <scope:team>
+
+npm team add <scope:team> <user>
+npm team rm <scope:team> <user>
+
+npm team ls <scope>|<scope:team>
+
+npm team edit <scope:team>
+.fi
+.RE
+.SH DESCRIPTION
+.P
+Used to manage teams in organizations, and change team memberships\. Does not
+handle permissions for packages\.
+.P
+Teams must always be fully qualified with the organization/scope they belond to
+when operating on them, separated by a colon (\fB:\fP)\. That is, if you have a
+\fBdevelopers\fP team on a \fBfoo\fP organization, you must always refer to that team as
+\fBfoo:developers\fP in these commands\.
+.RS 0
+.IP \(bu 2
+create / destroy:
+Create a new team, or destroy an existing one\.
+.IP \(bu 2
+add / rm:
+Add a user to an existing team, or remove a user from a team they belong to\.
+.IP \(bu 2
+ls:
+If performed on an organization name, will return a list of existing teams
+under that organization\. If performed on a team, it will instead return a list
+of all users belonging to that particular team\.
+
+.RE
+.SH DETAILS
+.P
+\fBnpm team\fP always operates directly on the current registry, configurable from
+the command line using \fB\-\-registry=<registry url>\fP\|\.
+.P
+In order to create teams and manage team membership, you must be a \fIteam admin\fR
+under the given organization\. Listing teams and team memberships may be done by
+any member of the organizations\.
+.P
+Organization creation and management of team admins and \fIorganization\fR members
+is done through the website, not the npm CLI\.
+.P
+To use teams to manage permissions on packages belonging to your organization,
+use the \fBnpm access\fP command to grant or revoke the appropriate permissions\.
+.SH SEE ALSO
+.RS 0
+.IP \(bu 2
+npm help access
+.IP \(bu 2
+npm help 7 registr
+
+.RE
+

node_modules/npm/man/man1/npm-test.1

@@ -0,0 +1,33 @@
+.TH "NPM\-TEST" "1" "March 2017" "" ""
+.SH "NAME"
+\fBnpm-test\fR \- Test a package
+.SH SYNOPSIS
+.P
+.RS 2
+.nf
+  npm test [\-\- <args>]
+
+  aliases: t, tst
+.fi
+.RE
+.SH DESCRIPTION
+.P
+This runs a package's "test" script, if one was provided\.
+.P
+To run tests as a condition of installation, set the \fBnpat\fP config to
+true\.
+.SH SEE ALSO
+.RS 0
+.IP \(bu 2
+npm help run\-script
+.IP \(bu 2
+npm help 7 scripts
+.IP \(bu 2
+npm help start
+.IP \(bu 2
+npm help restart
+.IP \(bu 2
+npm help stop
+
+.RE
+

node_modules/npm/man/man1/npm-uninstall.1

@@ -0,0 +1,68 @@
+.TH "NPM\-UNINSTALL" "1" "March 2017" "" ""
+.SH "NAME"
+\fBnpm-uninstall\fR \- Remove a package
+.SH SYNOPSIS
+.P
+.RS 2
+.nf
+npm uninstall [@<scope>/]<package> [\-\-save|\-\-save\-dev|\-\-save\-optional]
+npm rm (with any of the previous argument usage)
+.fi
+.RE
+.SH DESCRIPTION
+.P
+This uninstalls a package, completely removing everything npm installed
+on its behalf\.
+.P
+Example:
+.P
+.RS 2
+.nf
+npm uninstall sax
+.fi
+.RE
+.P
+In global mode (ie, with \fB\-g\fP or \fB\-\-global\fP appended to the command),
+it uninstalls the current package context as a global package\.
+.P
+\fBnpm uninstall\fP takes 3 exclusive, optional flags which save or update
+the package version in your main package\.json:
+.RS 0
+.IP \(bu 2
+\fB\-\-save\fP: Package will be removed from your \fBdependencies\fP\|\.
+.IP \(bu 2
+\fB\-\-save\-dev\fP: Package will be removed from your \fBdevDependencies\fP\|\.
+.IP \(bu 2
+\fB\-\-save\-optional\fP: Package will be removed from your \fBoptionalDependencies\fP\|\.
+
+.RE
+.P
+Scope is optional and follows the usual rules for npm help 7 \fBnpm\-scope\fP\|\.
+.P
+Examples:
+.P
+.RS 2
+.nf
+npm uninstall sax \-\-save
+npm uninstall @myorg/privatepackage \-\-save
+npm uninstall node\-tap \-\-save\-dev
+npm uninstall dtrace\-provider \-\-save\-optional
+.fi
+.RE
+.SH SEE ALSO
+.RS 0
+.IP \(bu 2
+npm help prune
+.IP \(bu 2
+npm help install
+.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 npmrc
+
+.RE
+

node_modules/npm/man/man1/npm-unpublish.1

@@ -0,0 +1,47 @@
+.TH "NPM\-UNPUBLISH" "1" "March 2017" "" ""
+.SH "NAME"
+\fBnpm-unpublish\fR \- Remove a package from the registry
+.SH SYNOPSIS
+.P
+.RS 2
+.nf
+npm unpublish [@<scope>/]<name>[@<version>]
+.fi
+.RE
+.SH WARNING
+.P
+\fBIt is generally considered bad behavior to remove versions of a library
+that others are depending on!\fR
+.P
+Consider using the \fBdeprecate\fP command
+instead, if your intent is to encourage users to upgrade\.
+.P
+There is plenty of room on the registry\.
+.SH DESCRIPTION
+.P
+This removes a package version from the registry, deleting its
+entry and removing the tarball\.
+.P
+If no version is specified, or if all versions are removed then
+the root package entry is removed from the registry entirely\.
+.P
+Even if a package version is unpublished, that specific name and
+version combination can never be reused\.  In order to publish the
+package again, a new version number must be used\.
+.P
+The scope is optional and follows the usual rules for npm help 7 \fBnpm\-scope\fP\|\.
+.SH SEE ALSO
+.RS 0
+.IP \(bu 2
+npm help deprecate
+.IP \(bu 2
+npm help publish
+.IP \(bu 2
+npm help 7 registry
+.IP \(bu 2
+npm help adduser
+.IP \(bu 2
+npm help owner
+
+.RE
+

node_modules/npm/man/man1/npm-update.1

@@ -0,0 +1,166 @@
+.TH "NPM\-UPDATE" "1" "March 2017" "" ""
+.SH "NAME"
+\fBnpm-update\fR \- Update a package
+.SH SYNOPSIS
+.P
+.RS 2
+.nf
+npm update [\-g] [<name> [<name> \.\.\.]]
+
+aliases: up, upgrade
+.fi
+.RE
+.SH DESCRIPTION
+.P
+This command will update all the packages listed to the latest version
+(specified by the \fBtag\fP config), respecting semver\.
+.P
+It will also install missing packages\. As with all commands that install
+packages, the \fB\-\-dev\fP flag will cause \fBdevDependencies\fP to be processed
+as well\.
+.P
+If the \fB\-g\fP flag is specified, this command will update globally installed
+packages\.
+.P
+If no package name is specified, all packages in the specified location (global
+or local) will be updated\.
+.P
+As of \fBnpm@2\.6\.1\fP, the \fBnpm update\fP will only inspect top\-level packages\.
+Prior versions of \fBnpm\fP would also recursively inspect all dependencies\.
+To get the old behavior, use \fBnpm \-\-depth 9999 update\fP\|\.
+.SH EXAMPLES
+.P
+IMPORTANT VERSION NOTE: these examples assume \fBnpm@2\.6\.1\fP or later\.  For
+older versions of \fBnpm\fP, you must specify \fB\-\-depth 0\fP to get the behavior
+described below\.
+.P
+For the examples below, assume that the current package is \fBapp\fP and it depends
+on dependencies, \fBdep1\fP (\fBdep2\fP, \.\. etc\.)\.  The published versions of \fBdep1\fP are:
+.P
+.RS 2
+.nf
+{
+  "dist\-tags": { "latest": "1\.2\.2" },
+  "versions": [
+    "1\.2\.2",
+    "1\.2\.1",
+    "1\.2\.0",
+    "1\.1\.2",
+    "1\.1\.1",
+    "1\.0\.0",
+    "0\.4\.1",
+    "0\.4\.0",
+    "0\.2\.0"
+  ]
+}
+.fi
+.RE
+.SS Caret Dependencies
+.P
+If \fBapp\fP\|'s \fBpackage\.json\fP contains:
+.P
+.RS 2
+.nf
+"dependencies": {
+  "dep1": "^1\.1\.1"
+}
+.fi
+.RE
+.P
+Then \fBnpm update\fP will install \fBdep1@1\.2\.2\fP, because \fB1\.2\.2\fP is \fBlatest\fP and
+\fB1\.2\.2\fP satisfies \fB^1\.1\.1\fP\|\.
+.SS Tilde Dependencies
+.P
+However, if \fBapp\fP\|'s \fBpackage\.json\fP contains:
+.P
+.RS 2
+.nf
+"dependencies": {
+  "dep1": "~1\.1\.1"
+}
+.fi
+.RE
+.P
+In this case, running \fBnpm update\fP will install \fBdep1@1\.1\.2\fP\|\.  Even though the \fBlatest\fP
+tag points to \fB1\.2\.2\fP, this version does not satisfy \fB~1\.1\.1\fP, which is equivalent
+to \fB>=1\.1\.1 <1\.2\.0\fP\|\.  So the highest\-sorting version that satisfies \fB~1\.1\.1\fP is used,
+which is \fB1\.1\.2\fP\|\.
+.SS Caret Dependencies below 1\.0\.0
+.P
+Suppose \fBapp\fP has a caret dependency on a version below \fB1\.0\.0\fP, for example:
+.P
+.RS 2
+.nf
+"dependencies": {
+  "dep1": "^0\.2\.0"
+}
+.fi
+.RE
+.P
+\fBnpm update\fP will install \fBdep1@0\.2\.0\fP, because there are no other
+versions which satisfy \fB^0\.2\.0\fP\|\.
+.P
+If the dependence were on \fB^0\.4\.0\fP:
+.P
+.RS 2
+.nf
+"dependencies": {
+  "dep1": "^0\.4\.0"
+}
+.fi
+.RE
+.P
+Then \fBnpm update\fP will install \fBdep1@0\.4\.1\fP, because that is the highest\-sorting
+version that satisfies \fB^0\.4\.0\fP (\fB>= 0\.4\.0 <0\.5\.0\fP)
+.SS Recording Updates with \fB\-\-save\fP
+.P
+When you want to update a package and save the new version as
+the minimum required dependency in \fBpackage\.json\fP, you can use
+\fBnpm update \-\-save\fP\|\.  For example if \fBpackage\.json\fP contains
+.P
+.RS 2
+.nf
+"dependencies": {
+  "dep1": "^1\.1\.1"
+}
+.fi
+.RE
+.P
+Then \fBnpm update \-\-save\fP will install \fBdep1@1\.2\.2\fP (i\.e\., \fBlatest\fP),
+and \fBpackage\.json\fP will be modified:
+.P
+.RS 2
+.nf
+"dependencies": {
+  "dep1": "^1\.2\.2"
+}
+.fi
+.RE
+.P
+Note that \fBnpm\fP will only write an updated version to \fBpackage\.json\fP
+if it installs a new package\.
+.SS Updating Globally\-Installed Packages
+.P
+\fBnpm update \-g\fP will apply the \fBupdate\fP action to each globally installed
+package that is \fBoutdated\fP \-\- that is, has a version that is different from
+\fBlatest\fP\|\.
+.P
+NOTE: If a package has been upgraded to a version newer than \fBlatest\fP, it will
+be \fIdowngraded\fR\|\.
+.SH SEE ALSO
+.RS 0
+.IP \(bu 2
+npm help install
+.IP \(bu 2
+npm help outdated
+.IP \(bu 2
+npm help shrinkwrap
+.IP \(bu 2
+npm help 7 registry
+.IP \(bu 2
+npm help 5 folders
+.IP \(bu 2
+npm help ls
+
+.RE
+

node_modules/npm/man/man1/npm-version.1

@@ -0,0 +1,124 @@
+.TH "NPM\-VERSION" "1" "March 2017" "" ""
+.SH "NAME"
+\fBnpm-version\fR \- Bump a package version
+.SH SYNOPSIS
+.P
+.RS 2
+.nf
+npm version [<newversion> | major | minor | patch | premajor | preminor | prepatch | prerelease]
+.fi
+.RE
+.SH DESCRIPTION
+.P
+Run this in a package directory to bump the version and write the new
+data back to \fBpackage\.json\fP and, if present, \fBnpm\-shrinkwrap\.json\fP\|\.
+.P
+The \fBnewversion\fP argument should be a valid semver string, \fIor\fR a
+valid second argument to semver\.inc (one of \fBpatch\fP, \fBminor\fP, \fBmajor\fP,
+\fBprepatch\fP, \fBpreminor\fP, \fBpremajor\fP, \fBprerelease\fP)\. In the second case,
+the existing version will be incremented by 1 in the specified field\.
+.P
+If run in a git repo, it will also create a version commit and tag\.
+This behavior is controlled by \fBgit\-tag\-version\fP (see below), and can 
+be disabled on the command line by running \fBnpm \-\-no\-git\-tag\-version version\fP\|\.
+It will fail if the working directory is not clean, unless the \fB\-\-force\fP
+flag is set\.
+.P
+If supplied with \fB\-\-message\fP (shorthand: \fB\-m\fP) config option, npm will
+use it as a commit message when creating a version commit\.  If the
+\fBmessage\fP config contains \fB%s\fP then that will be replaced with the
+resulting version number\.  For example:
+.P
+.RS 2
+.nf
+npm version patch \-m "Upgrade to %s for reasons"
+.fi
+.RE
+.P
+If the \fBsign\-git\-tag\fP config is set, then the tag will be signed using
+the \fB\-s\fP flag to git\.  Note that you must have a default GPG key set up
+in your git config for this to work properly\.  For example:
+.P
+.RS 2
+.nf
+$ npm config set sign\-git\-tag true
+$ npm version patch
+
+You need a passphrase to unlock the secret key for
+user: "isaacs (http://blog\.izs\.me/) <i@izs\.me>"
+2048\-bit RSA key, ID 6C481CF6, created 2010\-08\-31
+
+Enter passphrase:
+.fi
+.RE
+.P
+If \fBpreversion\fP, \fBversion\fP, or \fBpostversion\fP are in the \fBscripts\fP property of
+the package\.json, they will be executed as part of running \fBnpm version\fP\|\.
+.P
+The exact order of execution is as follows:
+.RS 0
+.IP 1. 3
+Check to make sure the git working directory is clean before we get started\.
+Your scripts may add files to the commit in future steps\.
+This step is skipped if the \fB\-\-force\fP flag is set\.
+.IP 2. 3
+Run the \fBpreversion\fP script\. These scripts have access to the old \fBversion\fP in package\.json\.
+A typical use would be running your full test suite before deploying\.
+Any files you want added to the commit should be explicitly added using \fBgit add\fP\|\.
+.IP 3. 3
+Bump \fBversion\fP in \fBpackage\.json\fP as requested (\fBpatch\fP, \fBminor\fP, \fBmajor\fP, etc)\. 
+.IP 4. 3
+Run the \fBversion\fP script\. These scripts have access to the new \fBversion\fP in package\.json
+(so they can incorporate it into file headers in generated files for example)\. 
+Again, scripts should explicitly add generated files to the commit using \fBgit add\fP\|\.
+.IP 5. 3
+Commit and tag\.
+.IP 6. 3
+Run the \fBpostversion\fP script\. Use it to clean up the file system or automatically push 
+the commit and/or tag\.
+
+.RE
+.P
+Take the following example:
+.P
+.RS 2
+.nf
+"scripts": {
+  "preversion": "npm test",
+  "version": "npm run build && git add \-A dist",
+  "postversion": "git push && git push \-\-tags && rm \-rf build/temp"
+}
+.fi
+.RE
+.P
+This runs all your tests, and proceeds only if they pass\. Then runs your \fBbuild\fP script, and
+adds everything in the \fBdist\fP directory to the commit\. After the commit, it pushes the new commit
+and tag up to the server, and deletes the \fBbuild/temp\fP directory\.
+.SH CONFIGURATION
+.SS git\-tag\-version
+.RS 0
+.IP \(bu 2
+Default: true
+.IP \(bu 2
+Type: Boolean
+
+.RE
+.P
+Commit and tag the version change\.
+.SH SEE ALSO
+.RS 0
+.IP \(bu 2
+npm help init
+.IP \(bu 2
+npm help run\-script
+.IP \(bu 2
+npm help 7 scripts
+.IP \(bu 2
+npm help 5 package\.json
+.IP \(bu 2
+npm help 7 semver
+.IP \(bu 2
+npm help 7 config
+
+.RE
+

node_modules/npm/man/man1/npm-view.1

@@ -0,0 +1,145 @@
+.TH "NPM\-VIEW" "1" "March 2017" "" ""
+.SH "NAME"
+\fBnpm-view\fR \- View registry info
+.SH SYNOPSIS
+.P
+.RS 2
+.nf
+npm view [@<scope>/]<name>[@<version>] [<field>[\.<subfield>]\.\.\.]
+npm v [@<scope>/]<name>[@<version>] [<field>[\.<subfield>]\.\.\.]
+.fi
+.RE
+.SH DESCRIPTION
+.P
+This command shows data about a package and prints it to the stream
+referenced by the \fBoutfd\fP config, which defaults to stdout\.
+.P
+To show the package registry entry for the \fBconnect\fP package, you can do
+this:
+.P
+.RS 2
+.nf
+npm view connect
+.fi
+.RE
+.P
+The default version is "latest" if unspecified\.
+.P
+Field names can be specified after the package descriptor\.
+For example, to show the dependencies of the \fBronn\fP package at version
+0\.3\.5, you could do the following:
+.P
+.RS 2
+.nf
+npm view ronn@0\.3\.5 dependencies
+.fi
+.RE
+.P
+You can view child fields by separating them with a period\.
+To view the git repository URL for the latest version of npm, you could
+do this:
+.P
+.RS 2
+.nf
+npm view npm repository\.url
+.fi
+.RE
+.P
+This makes it easy to view information about a dependency with a bit of
+shell scripting\.  For example, to view all the data about the version of
+opts that ronn depends on, you can do this:
+.P
+.RS 2
+.nf
+npm view opts@$(npm view ronn dependencies\.opts)
+.fi
+.RE
+.P
+For fields that are arrays, requesting a non\-numeric field will return
+all of the values from the objects in the list\.  For example, to get all
+the contributor names for the "express" project, you can do this:
+.P
+.RS 2
+.nf
+npm view express contributors\.email
+.fi
+.RE
+.P
+You may also use numeric indices in square braces to specifically select
+an item in an array field\.  To just get the email address of the first
+contributor in the list, you can do this:
+.P
+.RS 2
+.nf
+npm view express contributors[0]\.email
+.fi
+.RE
+.P
+Multiple fields may be specified, and will be printed one after another\.
+For exampls, to get all the contributor names and email addresses, you
+can do this:
+.P
+.RS 2
+.nf
+npm view express contributors\.name contributors\.email
+.fi
+.RE
+.P
+"Person" fields are shown as a string if they would be shown as an
+object\.  So, for example, this will show the list of npm contributors in
+the shortened string format\.  (See npm help 5 \fBpackage\.json\fP for more on this\.)
+.P
+.RS 2
+.nf
+npm view npm contributors
+.fi
+.RE
+.P
+If a version range is provided, then data will be printed for every
+matching version of the package\.  This will show which version of jsdom
+was required by each matching version of yui3:
+.P
+.RS 2
+.nf
+npm view yui3@'>0\.5\.4' dependencies\.jsdom
+.fi
+.RE
+.P
+To show the \fBconnect\fP package version history, you can do
+this:
+.P
+.RS 2
+.nf
+npm view connect versions
+.fi
+.RE
+.SH OUTPUT
+.P
+If only a single string field for a single version is output, then it
+will not be colorized or quoted, so as to enable piping the output to
+another command\. If the field is an object, it will be output as a JavaScript object literal\.
+.P
+If the \-\-json flag is given, the outputted fields will be JSON\.
+.P
+If the version range matches multiple versions, than each printed value
+will be prefixed with the version it applies to\.
+.P
+If multiple fields are requested, than each of them are prefixed with
+the field name\.
+.SH SEE ALSO
+.RS 0
+.IP \(bu 2
+npm help search
+.IP \(bu 2
+npm help 7 registry
+.IP \(bu 2
+npm help config
+.IP \(bu 2
+npm help 7 config
+.IP \(bu 2
+npm help 5 npmrc
+.IP \(bu 2
+npm help docs
+
+.RE
+

node_modules/npm/man/man1/npm-whoami.1

@@ -0,0 +1,26 @@
+.TH "NPM\-WHOAMI" "1" "March 2017" "" ""
+.SH "NAME"
+\fBnpm-whoami\fR \- Display npm username
+.SH SYNOPSIS
+.P
+.RS 2
+.nf
+npm whoami
+.fi
+.RE
+.SH DESCRIPTION
+.P
+Print the \fBusername\fP config to standard output\.
+.SH SEE ALSO
+.RS 0
+.IP \(bu 2
+npm help config
+.IP \(bu 2
+npm help 7 config
+.IP \(bu 2
+npm help 5 npmrc
+.IP \(bu 2
+npm help adduser
+
+.RE
+

node_modules/npm/man/man1/npm.1

@@ -0,0 +1,209 @@
+.TH "NPM" "1" "March 2017" "" ""
+.SH "NAME"
+\fBnpm\fR \- javascript package manager
+.SH SYNOPSIS
+.P
+.RS 2
+.nf
+npm <command> [args]
+.fi
+.RE
+.SH VERSION
+.P
+2.15.12
+.SH DESCRIPTION
+.P
+npm is the package manager for the Node JavaScript platform\.  It puts
+modules in place so that node can find them, and manages dependency
+conflicts intelligently\.
+.P
+It is extremely configurable to support a wide variety of use cases\.
+Most commonly, it is used to publish, discover, install, and develop node
+programs\.
+.P
+Run \fBnpm help\fP to get a list of available commands\.
+.SH INTRODUCTION
+.P
+You probably got npm because you want to install stuff\.
+.P
+Use \fBnpm install blerg\fP to install the latest version of "blerg"\.  Check out
+npm help \fBnpm\-install\fP for more info\.  It can do a lot of stuff\.
+.P
+Use the \fBnpm search\fP command to show everything that's available\.
+Use \fBnpm ls\fP to show everything you've installed\.
+.SH DEPENDENCIES
+.P
+If a package references to another package with a git URL, npm depends
+on a preinstalled git\.
+.P
+If one of the packages npm tries to install is a native node module and
+requires compiling of C++ Code, npm will use
+node\-gyp \fIhttps://github\.com/TooTallNate/node\-gyp\fR for that task\.
+For a Unix system, node\-gyp \fIhttps://github\.com/TooTallNate/node\-gyp\fR
+needs Python, make and a buildchain like GCC\. On Windows,
+Python and Microsoft Visual Studio C++ are needed\. Python 3 is
+not supported by node\-gyp \fIhttps://github\.com/TooTallNate/node\-gyp\fR\|\.
+For more information visit
+the node\-gyp repository \fIhttps://github\.com/TooTallNate/node\-gyp\fR and
+the node\-gyp Wiki \fIhttps://github\.com/TooTallNate/node\-gyp/wiki\fR\|\.
+.SH DIRECTORIES
+.P
+See npm help 5 \fBnpm\-folders\fP to learn about where npm puts stuff\.
+.P
+In particular, npm has two modes of operation:
+.RS 0
+.IP \(bu 2
+global mode:
+.br
+npm installs packages into the install prefix at
+\fBprefix/lib/node_modules\fP and bins are installed in \fBprefix/bin\fP\|\.
+.IP \(bu 2
+local mode:
+.br
+npm installs packages into the current project directory, which
+defaults to the current working directory\.  Packages are installed to
+\fB\|\./node_modules\fP, and bins are installed to \fB\|\./node_modules/\.bin\fP\|\.
+
+.RE
+.P
+Local mode is the default\.  Use \fB\-\-global\fP or \fB\-g\fP on any command to
+operate in global mode instead\.
+.SH DEVELOPER USAGE
+.P
+If you're using npm to develop and publish your code, check out the
+following help topics:
+.RS 0
+.IP \(bu 2
+json:
+Make a package\.json file\.  See npm help 5 \fBpackage\.json\fP\|\.
+.IP \(bu 2
+link:
+For linking your current working code into Node's path, so that you
+don't have to reinstall every time you make a change\.  Use
+\fBnpm link\fP to do this\.
+.IP \(bu 2
+install:
+It's a good idea to install things if you don't need the symbolic link\.
+Especially, installing other peoples code from the registry is done via
+\fBnpm install\fP
+.IP \(bu 2
+adduser:
+Create an account or log in\.  Credentials are stored in the
+user config file\.
+.IP \(bu 2
+publish:
+Use the \fBnpm publish\fP command to upload your code to the registry\.
+
+.RE
+.SH CONFIGURATION
+.P
+npm is extremely configurable\.  It reads its configuration options from
+5 places\.
+.RS 0
+.IP \(bu 2
+Command line switches:
+.br
+Set a config with \fB\-\-key val\fP\|\.  All keys take a value, even if they
+are booleans (the config parser doesn't know what the options are at
+the time of parsing\.)  If no value is provided, then the option is set
+to boolean \fBtrue\fP\|\.
+.IP \(bu 2
+Environment Variables:
+.br
+Set any config by prefixing the name in an environment variable with
+\fBnpm_config_\fP\|\.  For example, \fBexport npm_config_key=val\fP\|\.
+.IP \(bu 2
+User Configs:
+.br
+The file at $HOME/\.npmrc is an ini\-formatted list of configs\.  If
+present, it is parsed\.  If the \fBuserconfig\fP option is set in the cli
+or env, then that will be used instead\.
+.IP \(bu 2
+Global Configs:
+.br
+The file found at \.\./etc/npmrc (from the node executable, by default
+this resolves to /usr/local/etc/npmrc) will be parsed if it is found\.
+If the \fBglobalconfig\fP option is set in the cli, env, or user config,
+then that file is parsed instead\.
+.IP \(bu 2
+Defaults:
+.br
+npm's default configuration options are defined in
+lib/utils/config\-defs\.js\.  These must not be changed\.
+
+.RE
+.P
+See npm help 7 \fBnpm\-config\fP for much much more information\.
+.SH CONTRIBUTIONS
+.P
+Patches welcome!
+.RS 0
+.IP \(bu 2
+code:
+Read through npm help 7 \fBnpm\-coding\-style\fP if you plan to submit code\.
+You don't have to agree with it, but you do have to follow it\.
+.IP \(bu 2
+docs:
+If you find an error in the documentation, edit the appropriate markdown
+file in the "doc" folder\.  (Don't worry about generating the man page\.)
+
+.RE
+.P
+Contributors are listed in npm's \fBpackage\.json\fP file\.  You can view them
+easily by doing \fBnpm view npm contributors\fP\|\.
+.P
+If you would like to contribute, but don't know what to work on, read
+the contributing guidelines and check the issues list\.
+.RS 0
+.IP \(bu 2
+https://github\.com/npm/npm/wiki/Contributing\-Guidelines
+.IP \(bu 2
+https://github\.com/npm/npm/issues
+
+.RE
+.SH BUGS
+.P
+When you find issues, please report them:
+.RS 0
+.IP \(bu 2
+web:
+https://github\.com/npm/npm/issues
+
+.RE
+.P
+Be sure to include \fIall\fR of the output from the npm command that didn't work
+as expected\.  The \fBnpm\-debug\.log\fP file is also helpful to provide\.
+.P
+You can also look for isaacs in #node\.js on irc://irc\.freenode\.net\.  He
+will no doubt tell you to put the output in a gist or email\.
+.SH AUTHOR
+.P
+Isaac Z\. Schlueter \fIhttp://blog\.izs\.me/\fR ::
+isaacs \fIhttps://github\.com/isaacs/\fR ::
+@izs \fIhttp://twitter\.com/izs\fR ::
+i@izs\.me
+.SH SEE ALSO
+.RS 0
+.IP \(bu 2
+npm help help
+.IP \(bu 2
+npm help 7 faq
+.IP \(bu 2
+README
+.IP \(bu 2
+npm help 5 package\.json
+.IP \(bu 2
+npm help install
+.IP \(bu 2
+npm help config
+.IP \(bu 2
+npm help 7 config
+.IP \(bu 2
+npm help 5 npmrc
+.IP \(bu 2
+npm help 7 index
+.IP \(bu 2
+npm apihelp npm
+
+.RE
+

node_modules/npm/man/man3/npm-bin.3

@@ -0,0 +1,17 @@
+.TH "NPM\-BIN" "3" "March 2017" "" ""
+.SH "NAME"
+\fBnpm-bin\fR \- Display npm bin folder
+.SH SYNOPSIS
+.P
+.RS 2
+.nf
+npm\.commands\.bin(args, cb)
+.fi
+.RE
+.SH DESCRIPTION
+.P
+Print the folder where npm will install executables\.
+.P
+This function should not be used programmatically\.  Instead, just refer
+to the \fBnpm\.bin\fP property\.
+

node_modules/npm/man/man3/npm-bugs.3

@@ -0,0 +1,23 @@
+.TH "NPM\-BUGS" "3" "March 2017" "" ""
+.SH "NAME"
+\fBnpm-bugs\fR \- Bugs for a package in a web browser maybe
+.SH SYNOPSIS
+.P
+.RS 2
+.nf
+npm\.commands\.bugs(package, callback)
+.fi
+.RE
+.SH DESCRIPTION
+.P
+This command tries to guess at the likely location of a package's
+bug tracker URL, and then tries to open it using the \fB\-\-browser\fP
+config param\.
+.P
+Like other commands, the first parameter is an array\. This command only
+uses the first element, which is expected to be a package name with an
+optional version number\.
+.P
+This command will launch a browser, so this command may not be the most
+friendly for programmatic use\.
+

node_modules/npm/man/man3/npm-cache.3

@@ -0,0 +1,34 @@
+.TH "NPM\-CACHE" "3" "March 2017" "" ""
+.SH "NAME"
+\fBnpm-cache\fR \- manage the npm cache programmatically
+.SH SYNOPSIS
+.P
+.RS 2
+.nf
+npm\.commands\.cache([args], callback)
+
+// helpers
+npm\.commands\.cache\.clean([args], callback)
+npm\.commands\.cache\.add([args], callback)
+npm\.commands\.cache\.read(name, version, forceBypass, callback)
+.fi
+.RE
+.SH DESCRIPTION
+.P
+This acts much the same ways as the npm help cache command line
+functionality\.
+.P
+The callback is called with the package\.json data of the thing that is
+eventually added to or read from the cache\.
+.P
+The top level \fBnpm\.commands\.cache(\.\.\.)\fP functionality is a public
+interface, and like all commands on the \fBnpm\.commands\fP object, it will
+match the command line behavior exactly\.
+.P
+However, the cache folder structure and the cache helper functions are
+considered \fBinternal\fR API surface, and as such, may change in future
+releases of npm, potentially without warning or significant version
+incrementation\.
+.P
+Use at your own risk\.
+

node_modules/npm/man/man3/npm-commands.3

@@ -0,0 +1,28 @@
+.TH "NPM\-COMMANDS" "3" "March 2017" "" ""
+.SH "NAME"
+\fBnpm-commands\fR \- npm commands
+.SH SYNOPSIS
+.P
+.RS 2
+.nf
+npm\.commands[<command>](args, callback)
+.fi
+.RE
+.SH DESCRIPTION
+.P
+npm comes with a full set of commands, and each of the commands takes a
+similar set of arguments\.
+.P
+In general, all commands on the command object take an \fBarray\fR of positional
+argument \fBstrings\fR\|\. The last argument to any function is a callback\. Some
+commands are special and take other optional arguments\.
+.P
+All commands have their own man page\. See \fBman npm\-<command>\fP for command\-line
+usage, or \fBman 3 npm\-<command>\fP for programmatic usage\.
+.SH SEE ALSO
+.RS 0
+.IP \(bu 2
+npm help 7 index
+
+.RE
+

node_modules/npm/man/man3/npm-config.3

@@ -0,0 +1,49 @@
+.TH "NPM\-CONFIG" "3" "March 2017" "" ""
+.SH "NAME"
+\fBnpm-config\fR \- Manage the npm configuration files
+.SH SYNOPSIS
+.P
+.RS 2
+.nf
+npm\.commands\.config(args, callback)
+var val = npm\.config\.get(key)
+npm\.config\.set(key, val)
+.fi
+.RE
+.SH DESCRIPTION
+.P
+This function acts much the same way as the command\-line version\.  The first
+element in the array tells config what to do\. Possible values are:
+.RS 0
+.IP \(bu 2
+\fBset\fP
+  Sets a config parameter\.  The second element in \fBargs\fP is interpreted as the
+  key, and the third element is interpreted as the value\.
+.IP \(bu 2
+\fBget\fP
+  Gets the value of a config parameter\. The second element in \fBargs\fP is the
+  key to get the value of\.
+.IP \(bu 2
+\fBdelete\fP (\fBrm\fP or \fBdel\fP)
+  Deletes a parameter from the config\. The second element in \fBargs\fP is the
+  key to delete\.
+.IP \(bu 2
+\fBlist\fP (\fBls\fP)
+  Show all configs that aren't secret\. No parameters necessary\.
+.IP \(bu 2
+\fBedit\fP:
+  Opens the config file in the default editor\. This command isn't very useful
+  programmatically, but it is made available\.
+
+.RE
+.P
+To programmatically access npm configuration settings, or set them for
+the duration of a program, use the \fBnpm\.config\.set\fP and \fBnpm\.config\.get\fP
+functions instead\.
+.SH SEE ALSO
+.RS 0
+.IP \(bu 2
+npm apihelp npm
+
+.RE
+

node_modules/npm/man/man3/npm-deprecate.3

@@ -0,0 +1,43 @@
+.TH "NPM\-DEPRECATE" "3" "March 2017" "" ""
+.SH "NAME"
+\fBnpm-deprecate\fR \- Deprecate a version of a package
+.SH SYNOPSIS
+.P
+.RS 2
+.nf
+npm\.commands\.deprecate(args, callback)
+.fi
+.RE
+.SH DESCRIPTION
+.P
+This command will update the npm registry entry for a package, providing
+a deprecation warning to all who attempt to install it\.
+.P
+The 'args' parameter must have exactly two elements:
+.RS 0
+.IP \(bu 2
+\fBpackage[@version]\fP
+  The \fBversion\fP portion is optional, and may be either a range, or a
+  specific version, or a tag\.
+.IP \(bu 2
+\fBmessage\fP
+  The warning message that will be printed whenever a user attempts to
+  install the package\.
+
+.RE
+.P
+Note that you must be the package owner to deprecate something\.  See the
+\fBowner\fP and \fBadduser\fP help topics\.
+.P
+To un\-deprecate a package, specify an empty string (\fB""\fP) for the \fBmessage\fP argument\.
+.SH SEE ALSO
+.RS 0
+.IP \(bu 2
+npm apihelp publish
+.IP \(bu 2
+npm apihelp unpublish
+.IP \(bu 2
+npm help 7 registry
+
+.RE
+

node_modules/npm/man/man3/npm-docs.3

@@ -0,0 +1,23 @@
+.TH "NPM\-DOCS" "3" "March 2017" "" ""
+.SH "NAME"
+\fBnpm-docs\fR \- Docs for a package in a web browser maybe
+.SH SYNOPSIS
+.P
+.RS 2
+.nf
+npm\.commands\.docs(package, callback)
+.fi
+.RE
+.SH DESCRIPTION
+.P
+This command tries to guess at the likely location of a package's
+documentation URL, and then tries to open it using the \fB\-\-browser\fP
+config param\.
+.P
+Like other commands, the first parameter is an array\. This command only
+uses the first element, which is expected to be a package name with an
+optional version number\.
+.P
+This command will launch a browser, so this command may not be the most
+friendly for programmatic use\.
+

node_modules/npm/man/man3/npm-edit.3

@@ -0,0 +1,28 @@
+.TH "NPM\-EDIT" "3" "March 2017" "" ""
+.SH "NAME"
+\fBnpm-edit\fR \- Edit an installed package
+.SH SYNOPSIS
+.P
+.RS 2
+.nf
+npm\.commands\.edit(package, callback)
+.fi
+.RE
+.SH DESCRIPTION
+.P
+Opens the package folder in the default editor (or whatever you've
+configured as the npm \fBeditor\fP config \-\- see \fBnpm help config\fP\|\.)
+.P
+After it has been edited, the package is rebuilt so as to pick up any
+changes in compiled packages\.
+.P
+For instance, you can do \fBnpm install connect\fP to install connect
+into your package, and then \fBnpm\.commands\.edit(["connect"], callback)\fP
+to make a few changes to your locally installed copy\.
+.P
+The first parameter is a string array with a single element, the package
+to open\. The package can optionally have a version number attached\.
+.P
+Since this command opens an editor in a new process, be careful about where
+and how this is used\.
+

node_modules/npm/man/man3/npm-explore.3

@@ -0,0 +1,22 @@
+.TH "NPM\-EXPLORE" "3" "March 2017" "" ""
+.SH "NAME"
+\fBnpm-explore\fR \- Browse an installed package
+.SH SYNOPSIS
+.P
+.RS 2
+.nf
+npm\.commands\.explore(args, callback)
+.fi
+.RE
+.SH DESCRIPTION
+.P
+Spawn a subshell in the directory of the installed package specified\.
+.P
+If a command is specified, then it is run in the subshell, which then
+immediately terminates\.
+.P
+Note that the package is \fInot\fR automatically rebuilt afterwards, so be
+sure to use \fBnpm rebuild <pkg>\fP if you make any changes\.
+.P
+The first element in the 'args' parameter must be a package name\.  After that is the optional command, which can be any number of strings\. All of the strings will be combined into one, space\-delimited command\.
+

node_modules/npm/man/man3/npm-help-search.3

@@ -0,0 +1,41 @@
+.TH "NPM\-HELP\-SEARCH" "3" "March 2017" "" ""
+.SH "NAME"
+\fBnpm-help-search\fR \- Search the help pages
+.SH SYNOPSIS
+.P
+.RS 2
+.nf
+npm\.commands\.helpSearch(args, [silent,] callback)
+.fi
+.RE
+.SH DESCRIPTION
+.P
+This command is rarely useful, but it exists in the rare case that it is\.
+.P
+This command takes an array of search terms and returns the help pages that
+match in order of best match\.
+.P
+If there is only one match, then npm displays that help section\. If there
+are multiple results, the results are printed to the screen formatted and the
+array of results is returned\. Each result is an object with these properties:
+.RS 0
+.IP \(bu 2
+hits:
+A map of args to number of hits on that arg\. For example, {"npm": 3}
+.IP \(bu 2
+found:
+Total number of unique args that matched\.
+.IP \(bu 2
+totalHits:
+Total number of hits\.
+.IP \(bu 2
+lines:
+An array of all matching lines (and some adjacent lines)\.
+.IP \(bu 2
+file:
+Name of the file that matched
+
+.RE
+.P
+The silent parameter is not necessary not used, but it may in the future\.
+

node_modules/npm/man/man3/npm-init.3

@@ -0,0 +1,32 @@
+.TH "NPM" "" "March 2017" "" ""
+.SH "NAME"
+\fBnpm\fR
+.SH SYNOPSIS
+.P
+.RS 2
+.nf
+npm\.commands\.init(args, callback)
+.fi
+.RE
+.SH DESCRIPTION
+.P
+This will ask you a bunch of questions, and then write a package\.json for you\.
+.P
+It attempts to make reasonable guesses about what you want things to be set to,
+and then writes a package\.json file with the options you've selected\.
+.P
+If you already have a package\.json file, it'll read that first, and default to
+the options in there\.
+.P
+It is strictly additive, so it does not delete options from your package\.json
+without a really good reason to do so\.
+.P
+Since this function expects to be run on the command\-line, it doesn't work very
+well as a programmatically\. The best option is to roll your own, and since
+JavaScript makes it stupid simple to output formatted JSON, that is the
+preferred method\. If you're sure you want to handle command\-line prompting,
+then go ahead and use this programmatically\.
+.SH SEE ALSO
+.P
+npm help 5 package\.json
+

node_modules/npm/man/man3/npm-install.3

@@ -0,0 +1,23 @@
+.TH "NPM\-INSTALL" "3" "March 2017" "" ""
+.SH "NAME"
+\fBnpm-install\fR \- install a package programmatically
+.SH SYNOPSIS
+.P
+.RS 2
+.nf
+npm\.commands\.install([where,] packages, callback)
+.fi
+.RE
+.SH DESCRIPTION
+.P
+This acts much the same ways as installing on the command\-line\.
+.P
+The 'where' parameter is optional and only used internally, and it specifies
+where the packages should be installed to\.
+.P
+The 'packages' parameter is an array of strings\. Each element in the array is
+the name of a package to be installed\.
+.P
+Finally, 'callback' is a function that will be called when all packages have been
+installed or when an error has been encountered\.
+

node_modules/npm/man/man3/npm-link.3

@@ -0,0 +1,41 @@
+.TH "NPM\-LINK" "3" "March 2017" "" ""
+.SH "NAME"
+\fBnpm-link\fR \- Symlink a package folder
+.SH SYNOPSIS
+.P
+.RS 2
+.nf
+npm\.commands\.link(callback)
+npm\.commands\.link(packages, callback)
+.fi
+.RE
+.SH DESCRIPTION
+.P
+Package linking is a two\-step process\.
+.P
+Without parameters, link will create a globally\-installed
+symbolic link from \fBprefix/package\-name\fP to the current folder\.
+.P
+With a parameters, link will create a symlink from the local \fBnode_modules\fP
+folder to the global symlink\.
+.P
+When creating tarballs for \fBnpm publish\fP, the linked packages are
+"snapshotted" to their current state by resolving the symbolic links\.
+.P
+This is
+handy for installing your own stuff, so that you can work on it and test it
+iteratively without having to continually rebuild\.
+.P
+For example:
+.P
+.RS 2
+.nf
+npm\.commands\.link(cb)           # creates global link from the cwd
+                                # (say redis package)
+npm\.commands\.link('redis', cb)  # link\-install the package
+.fi
+.RE
+.P
+Now, any changes to the redis package will be reflected in
+the package in the current working directory
+

node_modules/npm/man/man3/npm-load.3

@@ -0,0 +1,34 @@
+.TH "NPM\-LOAD" "3" "March 2017" "" ""
+.SH "NAME"
+\fBnpm-load\fR \- Load config settings
+.SH SYNOPSIS
+.P
+.RS 2
+.nf
+npm\.load(conf, cb)
+.fi
+.RE
+.SH DESCRIPTION
+.P
+npm\.load() must be called before any other function call\.  Both parameters are
+optional, but the second is recommended\.
+.P
+The first parameter is an object containing command\-line config params, and the
+second parameter is a callback that will be called when npm is loaded and ready
+to serve\.
+.P
+The first parameter should follow a similar structure as the package\.json
+config object\.
+.P
+For example, to emulate the \-\-dev flag, pass an object that looks like this:
+.P
+.RS 2
+.nf
+{
+  "dev": true
+}
+.fi
+.RE
+.P
+For a list of all the available command\-line configs, see \fBnpm help config\fP
+

node_modules/npm/man/man3/npm-ls.3

@@ -0,0 +1,68 @@
+.TH "NPM\-LS" "3" "March 2017" "" ""
+.SH "NAME"
+\fBnpm-ls\fR \- List installed packages
+.SH SYNOPSIS
+.P
+.RS 2
+.nf
+npm\.commands\.ls(args, [silent,] callback)
+.fi
+.RE
+.SH DESCRIPTION
+.P
+This command will print to stdout all the versions of packages that are
+installed, as well as their dependencies, in a tree\-structure\. It will also
+return that data using the callback\.
+.P
+This command does not take any arguments, but args must be defined\.
+Beyond that, if any arguments are passed in, npm will politely warn that it
+does not take positional arguments, though you may set config flags
+like with any other command, such as \fBglobal\fP to list global packages\.
+.P
+It will print out extraneous, missing, and invalid packages\.
+.P
+If the silent parameter is set to true, nothing will be output to the screen,
+but the data will still be returned\.
+.P
+Callback is provided an error if one occurred, the full data about which
+packages are installed and which dependencies they will receive, and a
+"lite" data object which just shows which versions are installed where\.
+Note that the full data object is a circular structure, so care must be
+taken if it is serialized to JSON\.
+.SH CONFIGURATION
+.SS long
+.RS 0
+.IP \(bu 2
+Default: false
+.IP \(bu 2
+Type: Boolean
+
+.RE
+.P
+Show extended information\.
+.SS parseable
+.RS 0
+.IP \(bu 2
+Default: false
+.IP \(bu 2
+Type: Boolean
+
+.RE
+.P
+Show parseable output instead of tree view\.
+.SS global
+.RS 0
+.IP \(bu 2
+Default: false
+.IP \(bu 2
+Type: Boolean
+
+.RE
+.P
+List packages in the global install prefix instead of in the current
+project\.
+.P
+Note, if parseable is set or long isn't set, then duplicates will be trimmed\.
+This means that if a submodule has the same dependency as a parent module, then the
+dependency will only be output once\.
+

node_modules/npm/man/man3/npm-outdated.3

@@ -0,0 +1,17 @@
+.TH "NPM\-OUTDATED" "3" "March 2017" "" ""
+.SH "NAME"
+\fBnpm-outdated\fR \- Check for outdated packages
+.SH SYNOPSIS
+.P
+.RS 2
+.nf
+npm\.commands\.outdated([packages,] callback)
+.fi
+.RE
+.SH DESCRIPTION
+.P
+This command will check the registry to see if the specified packages are
+currently outdated\.
+.P
+If the 'packages' parameter is left out, npm will check all packages\.
+

node_modules/npm/man/man3/npm-owner.3

@@ -0,0 +1,43 @@
+.TH "NPM\-OWNER" "3" "March 2017" "" ""
+.SH "NAME"
+\fBnpm-owner\fR \- Manage package owners
+.SH SYNOPSIS
+.P
+.RS 2
+.nf
+npm\.commands\.owner(args, callback)
+.fi
+.RE
+.SH DESCRIPTION
+.P
+The first element of the 'args' parameter defines what to do, and the subsequent
+elements depend on the action\. Possible values for the action are (order of
+parameters are given in parenthesis):
+.RS 0
+.IP \(bu 2
+ls (package):
+List all the users who have access to modify a package and push new versions\.
+Handy when you need to know who to bug for help\.
+.IP \(bu 2
+add (user, package):
+Add a new user as a maintainer of a package\.  This user is enabled to modify
+metadata, publish new versions, and add other owners\.
+.IP \(bu 2
+rm (user, package):
+Remove a user from the package owner list\.  This immediately revokes their
+privileges\.
+
+.RE
+.P
+Note that there is only one level of access\.  Either you can modify a package,
+or you can't\.  Future versions may contain more fine\-grained access levels, but
+that is not implemented at this time\.
+.SH SEE ALSO
+.RS 0
+.IP \(bu 2
+npm apihelp publish
+.IP \(bu 2
+npm help 7 registry
+
+.RE
+

node_modules/npm/man/man3/npm-pack.3

@@ -0,0 +1,23 @@
+.TH "NPM\-PACK" "3" "March 2017" "" ""
+.SH "NAME"
+\fBnpm-pack\fR \- Create a tarball from a package
+.SH SYNOPSIS
+.P
+.RS 2
+.nf
+npm\.commands\.pack([packages,] callback)
+.fi
+.RE
+.SH DESCRIPTION
+.P
+For anything that's installable (that is, a package folder, tarball,
+tarball url, name@tag, name@version, or name), this command will fetch
+it to the cache, and then copy the tarball to the current working
+directory as \fB<name>\-<version>\.tgz\fP, and then write the filenames out to
+stdout\.
+.P
+If the same package is specified multiple times, then the file will be
+overwritten the second time\.
+.P
+If no arguments are supplied, then npm packs the current package folder\.
+

node_modules/npm/man/man3/npm-ping.3

@@ -0,0 +1,18 @@
+.TH "NPM\-PING" "3" "March 2017" "" ""
+.SH "NAME"
+\fBnpm-ping\fR \- Ping npm registry
+.SH SYNOPSIS
+.P
+.RS 2
+.nf
+npm\.registry\.ping(registry, options, function (er, pong))
+.fi
+.RE
+.SH DESCRIPTION
+.P
+Attempts to connect to the given registry, returning a \fBpong\fP
+object with various metadata if it succeeds\.
+.P
+This function is primarily useful for debugging connection issues
+to npm registries\.
+

node_modules/npm/man/man3/npm-prefix.3

@@ -0,0 +1,19 @@
+.TH "NPM\-PREFIX" "3" "March 2017" "" ""
+.SH "NAME"
+\fBnpm-prefix\fR \- Display prefix
+.SH SYNOPSIS
+.P
+.RS 2
+.nf
+npm\.commands\.prefix(args, callback)
+.fi
+.RE
+.SH DESCRIPTION
+.P
+Print the prefix to standard out\.
+.P
+\|'args' is never used and callback is never called with data\.
+\|'args' must be present or things will break\.
+.P
+This function is not useful programmatically
+

node_modules/npm/man/man3/npm-prune.3

@@ -0,0 +1,21 @@
+.TH "NPM\-PRUNE" "3" "March 2017" "" ""
+.SH "NAME"
+\fBnpm-prune\fR \- Remove extraneous packages
+.SH SYNOPSIS
+.P
+.RS 2
+.nf
+npm\.commands\.prune([packages,] callback)
+.fi
+.RE
+.SH DESCRIPTION
+.P
+This command removes "extraneous" packages\.
+.P
+The first parameter is optional, and it specifies packages to be removed\.
+.P
+No packages are specified, then all packages will be checked\.
+.P
+Extraneous packages are packages that are not listed on the parent
+package's dependencies list\.
+

node_modules/npm/man/man3/npm-publish.3

@@ -0,0 +1,41 @@
+.TH "NPM\-PUBLISH" "3" "March 2017" "" ""
+.SH "NAME"
+\fBnpm-publish\fR \- Publish a package
+.SH SYNOPSIS
+.P
+.RS 2
+.nf
+npm\.commands\.publish([packages,] callback)
+.fi
+.RE
+.SH DESCRIPTION
+.P
+Publishes a package to the registry so that it can be installed by name\.
+Possible values in the 'packages' array are:
+.RS 0
+.IP \(bu 2
+\fB<folder>\fP:
+A folder containing a package\.json file
+.IP \(bu 2
+\fB<tarball>\fP:
+A url or file path to a gzipped tar archive containing a single folder
+with a package\.json file inside\.
+
+.RE
+.P
+If the package array is empty, npm will try to publish something in the
+current working directory\.
+.P
+This command could fails if one of the packages specified already exists in
+the registry\.  Overwrites when the "force" environment variable is set\.
+.SH SEE ALSO
+.RS 0
+.IP \(bu 2
+npm help 7 registry
+.IP \(bu 2
+npm help adduser
+.IP \(bu 2
+npm apihelp owner
+
+.RE
+

node_modules/npm/man/man3/npm-rebuild.3

@@ -0,0 +1,19 @@
+.TH "NPM\-REBUILD" "3" "March 2017" "" ""
+.SH "NAME"
+\fBnpm-rebuild\fR \- Rebuild a package
+.SH SYNOPSIS
+.P
+.RS 2
+.nf
+npm\.commands\.rebuild([packages,] callback)
+.fi
+.RE
+.SH DESCRIPTION
+.P
+This command runs the \fBnpm build\fP command on each of the matched packages\.  This is useful
+when you install a new version of node, and must recompile all your C++ addons with
+the new binary\. If no 'packages' parameter is specify, every package will be rebuilt\.
+.SH CONFIGURATION
+.P
+See \fBnpm help build\fP
+

node_modules/npm/man/man3/npm-repo.3

@@ -0,0 +1,23 @@
+.TH "NPM\-REPO" "3" "March 2017" "" ""
+.SH "NAME"
+\fBnpm-repo\fR \- Open package repository page in the browser
+.SH SYNOPSIS
+.P
+.RS 2
+.nf
+npm\.commands\.repo(package, callback)
+.fi
+.RE
+.SH DESCRIPTION
+.P
+This command tries to guess at the likely location of a package's
+repository URL, and then tries to open it using the \fB\-\-browser\fP
+config param\.
+.P
+Like other commands, the first parameter is an array\. This command only
+uses the first element, which is expected to be a package name with an
+optional version number\.
+.P
+This command will launch a browser, so this command may not be the most
+friendly for programmatic use\.
+

node_modules/npm/man/man3/npm-restart.3

@@ -0,0 +1,58 @@
+.TH "NPM\-RESTART" "3" "March 2017" "" ""
+.SH "NAME"
+\fBnpm-restart\fR \- Restart a package
+.SH SYNOPSIS
+.P
+.RS 2
+.nf
+npm\.commands\.restart(packages, callback)
+.fi
+.RE
+.SH DESCRIPTION
+.P
+This restarts a package (or multiple packages)\.
+.P
+This runs a package's "stop", "restart", and "start" scripts, and associated
+pre\- and post\- scripts, in the order given below:
+.RS 0
+.IP 1. 3
+prerestart
+.IP 2. 3
+prestop
+.IP 3. 3
+stop
+.IP 4. 3
+poststop
+.IP 5. 3
+restart
+.IP 6. 3
+prestart
+.IP 7. 3
+start
+.IP 8. 3
+poststart
+.IP 9. 3
+postrestart
+
+.RE
+.P
+If no version is specified, then it restarts the "active" version\.
+.P
+npm can restart multiple packages\. Just specify multiple packages in
+the \fBpackages\fP parameter\.
+.SH NOTE
+.P
+Note that the "restart" script is run \fBin addition to\fR the "stop"
+and "start" scripts, not instead of them\.
+.P
+This is the behavior as of \fBnpm\fP major version 2\.  A change in this
+behavior will be accompanied by an increase in major version number
+.SH SEE ALSO
+.RS 0
+.IP \(bu 2
+npm apihelp start
+.IP \(bu 2
+npm apihelp stop
+
+.RE
+

node_modules/npm/man/man3/npm-root.3

@@ -0,0 +1,19 @@
+.TH "NPM\-ROOT" "3" "March 2017" "" ""
+.SH "NAME"
+\fBnpm-root\fR \- Display npm root
+.SH SYNOPSIS
+.P
+.RS 2
+.nf
+npm\.commands\.root(args, callback)
+.fi
+.RE
+.SH DESCRIPTION
+.P
+Print the effective \fBnode_modules\fP folder to standard out\.
+.P
+\|'args' is never used and callback is never called with data\.
+\|'args' must be present or things will break\.
+.P
+This function is not useful programmatically\.
+

node_modules/npm/man/man3/npm-run-script.3

@@ -0,0 +1,37 @@
+.TH "NPM\-RUN\-SCRIPT" "3" "March 2017" "" ""
+.SH "NAME"
+\fBnpm-run-script\fR \- Run arbitrary package scripts
+.SH SYNOPSIS
+.P
+.RS 2
+.nf
+npm\.commands\.run\-script(args, callback)
+.fi
+.RE
+.SH DESCRIPTION
+.P
+This runs an arbitrary command from a package's "scripts" object\.
+.P
+It is used by the test, start, restart, and stop commands, but can be
+called directly, as well\.
+.P
+The 'args' parameter is an array of strings\. Behavior depends on the number
+of elements\.  If there is only one element, npm assumes that the element
+represents a command to be run on the local repository\. If there is more than
+one element, then the first is assumed to be the package and the second is
+assumed to be the command to run\. All other elements are ignored\.
+.SH SEE ALSO
+.RS 0
+.IP \(bu 2
+npm help 7 scripts
+.IP \(bu 2
+npm apihelp test
+.IP \(bu 2
+npm apihelp start
+.IP \(bu 2
+npm apihelp restart
+.IP \(bu 2
+npm apihelp stop
+
+.RE
+

node_modules/npm/man/man3/npm-search.3

@@ -0,0 +1,52 @@
+.TH "NPM\-SEARCH" "3" "March 2017" "" ""
+.SH "NAME"
+\fBnpm-search\fR \- Search for packages
+.SH SYNOPSIS
+.P
+.RS 2
+.nf
+npm\.commands\.search(searchTerms, [silent,] [staleness,] callback)
+.fi
+.RE
+.SH DESCRIPTION
+.P
+Search the registry for packages matching the search terms\. The available parameters are:
+.RS 0
+.IP \(bu 2
+searchTerms:
+Array of search terms\. These terms are case\-insensitive\.
+.IP \(bu 2
+silent:
+If true, npm will not log anything to the console\.
+.IP \(bu 2
+staleness:
+This is the threshold for stale packages\. "Fresh" packages are not refreshed
+from the registry\. This value is measured in seconds\.
+.IP \(bu 2
+callback:
+Returns an object where each key is the name of a package, and the value
+is information about that package along with a 'words' property, which is
+a space\-delimited string of all of the interesting words in that package\.
+The only properties included are those that are searched, which generally include:
+.RS 0
+.IP \(bu 2
+name
+.IP \(bu 2
+description
+.IP \(bu 2
+maintainers
+.IP \(bu 2
+url
+.IP \(bu 2
+keywords
+
+.RE
+
+.RE
+.P
+A search on the registry excludes any result that does not match all of the
+search terms\. It also removes any items from the results that contain an
+excluded term (the "searchexclude" config)\. The search is case insensitive
+and doesn't try to read your mind (it doesn't do any verb tense matching or the
+like)\.
+

node_modules/npm/man/man3/npm-shrinkwrap.3

@@ -0,0 +1,24 @@
+.TH "NPM\-SHRINKWRAP" "3" "March 2017" "" ""
+.SH "NAME"
+\fBnpm-shrinkwrap\fR \- programmatically generate package shrinkwrap file
+.SH SYNOPSIS
+.P
+.RS 2
+.nf
+npm\.commands\.shrinkwrap(args, [silent,] callback)
+.fi
+.RE
+.SH DESCRIPTION
+.P
+This acts much the same ways as shrinkwrapping on the command\-line\.
+.P
+This command does not take any arguments, but 'args' must be defined\.
+Beyond that, if any arguments are passed in, npm will politely warn that it
+does not take positional arguments\.
+.P
+If the 'silent' parameter is set to true, nothing will be output to the screen,
+but the shrinkwrap file will still be written\.
+.P
+Finally, 'callback' is a function that will be called when the shrinkwrap has
+been saved\.
+

node_modules/npm/man/man3/npm-start.3

@@ -0,0 +1,17 @@
+.TH "NPM\-START" "3" "March 2017" "" ""
+.SH "NAME"
+\fBnpm-start\fR \- Start a package
+.SH SYNOPSIS
+.P
+.RS 2
+.nf
+npm\.commands\.start(packages, callback)
+.fi
+.RE
+.SH DESCRIPTION
+.P
+This runs a package's "start" script, if one was provided\.
+.P
+npm can start multiple packages\. Just specify multiple packages in the
+\fBpackages\fP parameter\.
+

node_modules/npm/man/man3/npm-stop.3

@@ -0,0 +1,17 @@
+.TH "NPM\-STOP" "3" "March 2017" "" ""
+.SH "NAME"
+\fBnpm-stop\fR \- Stop a package
+.SH SYNOPSIS
+.P
+.RS 2
+.nf
+npm\.commands\.stop(packages, callback)
+.fi
+.RE
+.SH DESCRIPTION
+.P
+This runs a package's "stop" script, if one was provided\.
+.P
+npm can run stop on multiple packages\. Just specify multiple packages
+in the \fBpackages\fP parameter\.
+

node_modules/npm/man/man3/npm-tag.3

@@ -0,0 +1,27 @@
+.TH "NPM\-TAG" "3" "March 2017" "" ""
+.SH "NAME"
+\fBnpm-tag\fR \- Tag a published version
+.SH SYNOPSIS
+.P
+.RS 2
+.nf
+npm\.commands\.tag(package@version, tag, callback)
+.fi
+.RE
+.SH DESCRIPTION
+.P
+Tags the specified version of the package with the specified tag, or the
+\fB\-\-tag\fP config if not specified\.
+.P
+The 'package@version' is an array of strings, but only the first two elements are
+currently used\.
+.P
+The first element must be in the form package@version, where package
+is the package name and version is the version number (much like installing a
+specific version)\.
+.P
+The second element is the name of the tag to tag this version with\. If this
+parameter is missing or falsey (empty), the default from the config will be
+used\. For more information about how to set this config, check
+\fBman 3 npm\-config\fP for programmatic usage or \fBman npm\-config\fP for cli usage\.
+

node_modules/npm/man/man3/npm-test.3

@@ -0,0 +1,20 @@
+.TH "NPM\-TEST" "3" "March 2017" "" ""
+.SH "NAME"
+\fBnpm-test\fR \- Test a package
+.SH SYNOPSIS
+.P
+.RS 2
+.nf
+  npm\.commands\.test(packages, callback)
+.fi
+.RE
+.SH DESCRIPTION
+.P
+This runs a package's "test" script, if one was provided\.
+.P
+To run tests as a condition of installation, set the \fBnpat\fP config to
+true\.
+.P
+npm can run tests on multiple packages\. Just specify multiple packages
+in the \fBpackages\fP parameter\.
+

node_modules/npm/man/man3/npm-uninstall.3

@@ -0,0 +1,20 @@
+.TH "NPM\-UNINSTALL" "3" "March 2017" "" ""
+.SH "NAME"
+\fBnpm-uninstall\fR \- uninstall a package programmatically
+.SH SYNOPSIS
+.P
+.RS 2
+.nf
+npm\.commands\.uninstall(packages, callback)
+.fi
+.RE
+.SH DESCRIPTION
+.P
+This acts much the same ways as uninstalling on the command\-line\.
+.P
+The 'packages' parameter is an array of strings\. Each element in the array is
+the name of a package to be uninstalled\.
+.P
+Finally, 'callback' is a function that will be called when all packages have been
+uninstalled or when an error has been encountered\.
+

node_modules/npm/man/man3/npm-unpublish.3

@@ -0,0 +1,24 @@
+.TH "NPM\-UNPUBLISH" "3" "March 2017" "" ""
+.SH "NAME"
+\fBnpm-unpublish\fR \- Remove a package from the registry
+.SH SYNOPSIS
+.P
+.RS 2
+.nf
+npm\.commands\.unpublish(package, callback)
+.fi
+.RE
+.SH DESCRIPTION
+.P
+This removes a package version from the registry, deleting its
+entry and removing the tarball\.
+.P
+The package parameter must be defined\.
+.P
+Only the first element in the package parameter is used\.  If there is no first
+element, then npm assumes that the package at the current working directory
+is what is meant\.
+.P
+If no version is specified, or if all versions are removed then
+the root package entry is removed from the registry entirely\.
+

node_modules/npm/man/man3/npm-update.3

@@ -0,0 +1,26 @@
+.TH "NPM\-UPDATE" "3" "March 2017" "" ""
+.SH "NAME"
+\fBnpm-update\fR \- Update a package
+.SH SYNOPSIS
+.P
+.RS 2
+.nf
+npm\.commands\.update(packages, callback)
+.fi
+.RE
+.TH "DESCRIPTION" "" "March 2017" "" ""
+.SH "NAME"
+\fBDESCRIPTION\fR
+.P
+Updates a package, upgrading it to the latest version\. It also installs any
+missing packages\.
+.P
+The \fBpackages\fP argument is an array of packages to update\. The \fBcallback\fP
+parameter will be called when done or when an error occurs\.
+.SH SEE ALSO
+.RS 0
+.IP \(bu 2
+npm help update
+
+.RE
+

node_modules/npm/man/man3/npm-version.3

@@ -0,0 +1,22 @@
+.TH "NPM\-VERSION" "3" "March 2017" "" ""
+.SH "NAME"
+\fBnpm-version\fR \- Bump a package version
+.SH SYNOPSIS
+.P
+.RS 2
+.nf
+npm\.commands\.version(newversion, callback)
+.fi
+.RE
+.SH DESCRIPTION
+.P
+Run this in a package directory to bump the version and write the new
+data back to the package\.json file\.
+.P
+If run in a git repo, it will also create a version commit and tag, and
+fail if the repo is not clean\.
+.P
+Like all other commands, this function takes a string array as its first
+parameter\. The difference, however, is this function will fail if it does
+not have exactly one element\. The only element should be a version number\.
+

node_modules/npm/man/man3/npm-view.3

@@ -0,0 +1,131 @@
+.TH "NPM\-VIEW" "3" "March 2017" "" ""
+.SH "NAME"
+\fBnpm-view\fR \- View registry info
+.SH SYNOPSIS
+.P
+.RS 2
+.nf
+npm\.commands\.view(args, [silent,] callback)
+.fi
+.RE
+.SH DESCRIPTION
+.P
+This command shows data about a package and prints it to the stream
+referenced by the \fBoutfd\fP config, which defaults to stdout\.
+.P
+The "args" parameter is an ordered list that closely resembles the command\-line
+usage\. The elements should be ordered such that the first element is
+the package and version (package@version)\. The version is optional\. After that,
+the rest of the parameters are fields with optional subfields ("field\.subfield")
+which can be used to get only the information desired from the registry\.
+.P
+The callback will be passed all of the data returned by the query\.
+.P
+For example, to get the package registry entry for the \fBconnect\fP package,
+you can do this:
+.P
+.RS 2
+.nf
+npm\.commands\.view(["connect"], callback)
+.fi
+.RE
+.P
+If no version is specified, "latest" is assumed\.
+.P
+Field names can be specified after the package descriptor\.
+For example, to show the dependencies of the \fBronn\fP package at version
+0\.3\.5, you could do the following:
+.P
+.RS 2
+.nf
+npm\.commands\.view(["ronn@0\.3\.5", "dependencies"], callback)
+.fi
+.RE
+.P
+You can view child field by separating them with a period\.
+To view the git repository URL for the latest version of npm, you could
+do this:
+.P
+.RS 2
+.nf
+npm\.commands\.view(["npm", "repository\.url"], callback)
+.fi
+.RE
+.P
+For fields that are arrays, requesting a non\-numeric field will return
+all of the values from the objects in the list\.  For example, to get all
+the contributor names for the "express" project, you can do this:
+.P
+.RS 2
+.nf
+npm\.commands\.view(["express", "contributors\.email"], callback)
+.fi
+.RE
+.P
+You may also use numeric indices in square braces to specifically select
+an item in an array field\.  To just get the email address of the first
+contributor in the list, you can do this:
+.P
+.RS 2
+.nf
+npm\.commands\.view(["express", "contributors[0]\.email"], callback)
+.fi
+.RE
+.P
+Multiple fields may be specified, and will be printed one after another\.
+For exampls, to get all the contributor names and email addresses, you
+can do this:
+.P
+.RS 2
+.nf
+npm\.commands\.view(["express", "contributors\.name", "contributors\.email"], callback)
+.fi
+.RE
+.P
+"Person" fields are shown as a string if they would be shown as an
+object\.  So, for example, this will show the list of npm contributors in
+the shortened string format\.  (See \fBnpm help json\fP for more on this\.)
+.P
+.RS 2
+.nf
+npm\.commands\.view(["npm", "contributors"], callback)
+.fi
+.RE
+.P
+If a version range is provided, then data will be printed for every
+matching version of the package\.  This will show which version of jsdom
+was required by each matching version of yui3:
+.P
+.RS 2
+.nf
+npm\.commands\.view(["yui3@>0\.5\.4", "dependencies\.jsdom"], callback)
+.fi
+.RE
+.SH OUTPUT
+.P
+If only a single string field for a single version is output, then it
+will not be colorized or quoted, so as to enable piping the output to
+another command\.
+.P
+If the version range matches multiple versions, than each printed value
+will be prefixed with the version it applies to\.
+.P
+If multiple fields are requested, than each of them are prefixed with
+the field name\.
+.P
+Console output can be disabled by setting the 'silent' parameter to true\.
+.SH RETURN VALUE
+.P
+The data returned will be an object in this formation:
+.P
+.RS 2
+.nf
+{ <version>:
+  { <field>: <value>
+  , \.\.\. }
+, \.\.\. }
+.fi
+.RE
+.P
+corresponding to the list of fields selected\.
+

node_modules/npm/man/man3/npm-whoami.3

@@ -0,0 +1,19 @@
+.TH "NPM\-WHOAMI" "3" "March 2017" "" ""
+.SH "NAME"
+\fBnpm-whoami\fR \- Display npm username
+.SH SYNOPSIS
+.P
+.RS 2
+.nf
+npm\.commands\.whoami(args, callback)
+.fi
+.RE
+.SH DESCRIPTION
+.P
+Print the \fBusername\fP config to standard output\.
+.P
+\|'args' is never used and callback is never called with data\.
+\|'args' must be present or things will break\.
+.P
+This function is not useful programmatically
+

node_modules/npm/man/man3/npm.3

@@ -0,0 +1,124 @@
+.TH "NPM" "3" "March 2017" "" ""
+.SH "NAME"
+\fBnpm\fR \- javascript package manager
+.SH SYNOPSIS
+.P
+.RS 2
+.nf
+var npm = require("npm")
+npm\.load([configObject, ]function (er, npm) {
+  // use the npm object, now that it's loaded\.
+
+  npm\.config\.set(key, val)
+  val = npm\.config\.get(key)
+
+  console\.log("prefix = %s", npm\.prefix)
+
+  npm\.commands\.install(["package"], cb)
+})
+.fi
+.RE
+.SH VERSION
+.P
+2.15.12
+.SH DESCRIPTION
+.P
+This is the API documentation for npm\.
+To find documentation of the command line
+client, see npm help \fBnpm\fP\|\.
+.P
+Prior to using npm's commands, \fBnpm\.load()\fP must be called\.  If you provide
+\fBconfigObject\fP as an object map of top\-level configs, they override the values
+stored in the various config locations\. In the npm command line client, this
+set of configs is parsed from the command line options\. Additional
+configuration params are loaded from two configuration files\. See
+npm help \fBnpm\-config\fP, npm help 7 \fBnpm\-config\fP, and npm help 5 \fBnpmrc\fP for more information\.
+.P
+After that, each of the functions are accessible in the
+commands object: \fBnpm\.commands\.<cmd>\fP\|\.  See npm help 7 \fBnpm\-index\fP for a list of
+all possible commands\.
+.P
+All commands on the command object take an \fBarray\fR of positional argument
+\fBstrings\fR\|\. The last argument to any function is a callback\. Some
+commands take other optional arguments\.
+.P
+Configs cannot currently be set on a per function basis, as each call to
+npm\.config\.set will change the value for \fIall\fR npm commands in that process\.
+.P
+To find API documentation for a specific command, run the \fBnpm apihelp\fP
+command\.
+.SH METHODS AND PROPERTIES
+.RS 0
+.IP \(bu 2
+\fBnpm\.load(configs, cb)\fP
+  Load the configuration params, and call the \fBcb\fP function once the
+  globalconfig and userconfig files have been loaded as well, or on
+  nextTick if they've already been loaded\.
+.IP \(bu 2
+\fBnpm\.config\fP
+  An object for accessing npm configuration parameters\.
+.RS 0
+.IP \(bu 2
+\fBnpm\.config\.get(key)\fP
+.IP \(bu 2
+\fBnpm\.config\.set(key, val)\fP
+.IP \(bu 2
+\fBnpm\.config\.del(key)\fP
+
+.RE
+.IP \(bu 2
+\fBnpm\.dir\fP or \fBnpm\.root\fP
+  The \fBnode_modules\fP directory where npm will operate\.
+.IP \(bu 2
+\fBnpm\.prefix\fP
+  The prefix where npm is operating\.  (Most often the current working
+  directory\.)
+.IP \(bu 2
+\fBnpm\.cache\fP
+  The place where npm keeps JSON and tarballs it fetches from the
+  registry (or uploads to the registry)\.
+.IP \(bu 2
+\fBnpm\.tmp\fP
+  npm's temporary working directory\.
+.IP \(bu 2
+\fBnpm\.deref\fP
+  Get the "real" name for a command that has either an alias or
+  abbreviation\.
+
+.RE
+.SH MAGIC
+.P
+For each of the methods in the \fBnpm\.commands\fP object, a method is added to the
+npm object, which takes a set of positional string arguments rather than an
+array and a callback\.
+.P
+If the last argument is a callback, then it will use the supplied
+callback\.  However, if no callback is provided, then it will print out
+the error or results\.
+.P
+For example, this would work in a node repl:
+.P
+.RS 2
+.nf
+> npm = require("npm")
+> npm\.load()  // wait a sec\.\.\.
+> npm\.install("dnode", "express")
+.fi
+.RE
+.P
+Note that that \fIwon't\fR work in a node program, since the \fBinstall\fP
+method will get called before the configuration load is completed\.
+.SH ABBREVS
+.P
+In order to support \fBnpm ins foo\fP instead of \fBnpm install foo\fP, the
+\fBnpm\.commands\fP object has a set of abbreviations as well as the full
+method names\.  Use the \fBnpm\.deref\fP method to find the real name\.
+.P
+For example:
+.P
+.RS 2
+.nf
+var cmd = npm\.deref("unp") // cmd === "unpublish"
+.fi
+.RE
+

node_modules/npm/man/man5/npm-folders.5

@@ -0,0 +1,229 @@
+.TH "NPM\-FOLDERS" "5" "March 2017" "" ""
+.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, this is the exact 
+location of the node\.exe binary\.  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~/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 \fBbar@1\.2\.3\fP and \fBbaz@1\.2\.3\fP, those are
+installed in foo's \fBnode_modules\fP 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 \fBblerg@1\.x\fP,
+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 \fBbaz@2\.x\fP, it cannot
+re\-use the \fBbaz@1\.2\.3\fP installed in the parent \fBnode_modules\fP 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 7 faq
+.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
+

node_modules/npm/man/man5/npm-global.5

@@ -0,0 +1,229 @@
+.TH "NPM\-FOLDERS" "5" "March 2017" "" ""
+.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, this is the exact 
+location of the node\.exe binary\.  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~/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 \fBbar@1\.2\.3\fP and \fBbaz@1\.2\.3\fP, those are
+installed in foo's \fBnode_modules\fP 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 \fBblerg@1\.x\fP,
+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 \fBbaz@2\.x\fP, it cannot
+re\-use the \fBbaz@1\.2\.3\fP installed in the parent \fBnode_modules\fP 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 7 faq
+.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
+

node_modules/npm/man/man5/npm-json.5

@@ -0,0 +1,923 @@
+.TH "PACKAGE\.JSON" "5" "March 2017" "" ""
+.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
+The \fImost\fR important things in your package\.json are the name and version fields\.
+Those are actually required, and your package won't install without
+them\.  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\.
+.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
+The \fImost\fR important things in your package\.json are the name and version fields\.
+Those are actually required, and your package won't install without
+them\.  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\.
+.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
+\fBNOTE\fR: This is \fInot\fR the same as "url"\.  If you put a "url" field,
+then the registry will think it's a redirection to your package that has
+been published somewhere else, and spit at you\.
+.P
+Literally\.  Spit\.  I'm so not kidding\.
+.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://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" : "http://opensource\.org/licenses/ISC"
+  }
+}
+
+// Not valid metadata
+{ "licenses" :
+  [
+    { "type": "MIT"
+    , "url": "http://www\.opensource\.org/licenses/mit\-license\.php"
+    }
+  , { "type": "Apache\-2\.0"
+    , "url": "http://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 "files" field is an array of files to include in your project\.  If
+you name a folder in the array, then it will also include the files
+inside that folder\. (Unless they would be ignored by another rule\.)
+.P
+You can also provide a "\.npmignore" file in the root of your package or
+in subdirectories, which will keep files from being included, even
+if they would be picked up by the files array\.  The \fB\|\.npmignore\fP file
+works just like a \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 (any casing and file extension)
+.IP \(bu 2
+\fBLICENSE\fP / \fBLICENCE\fP
+.IP \(bu 2
+The file in the "main" field
+
+.RE
+.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
+
+.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 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/npm\.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": "gist:11081aaa281"
+
+"repository": "bitbucket:example/repo"
+
+"repository": "gitlab:another/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\-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 can be of the form:
+.P
+.RS 2
+.nf
+git://github\.com/user/project\.git#commit\-ish
+git+ssh://user@hostname:project\.git#commit\-ish
+git+ssh://user@hostname/project\.git#commit\-ish
+git+http://user@hostname/project/blah\.git#commit\-ish
+git+https://user@hostname/project/blah\.git#commit\-ish
+.fi
+.RE
+.P
+The \fBcommit\-ish\fP can be any tag, sha, or branch which can be supplied as
+an argument to \fBgit checkout\fP\|\.  The default is \fBmaster\fP\|\.
+.SH 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": "visionmedia/express",
+    "mocha": "visionmedia/mocha#4727d357ea"
+  }
+}
+.fi
+.RE
+.SH 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 \-\-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 \fBprepublish\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": {
+    "prepublish": "coffee \-o lib/ \-c src/waza\.coffee"
+  },
+  "main": "lib/waza\.js"
+}
+.fi
+.RE
+.P
+The \fBprepublish\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 \fIhttp://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:
+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 will produce warnings when your package is installed as a dependency\.
+.SH engineStrict
+.P
+\fBNOTE: This feature is deprecated and will be removed in npm 3\.0\.0\.\fR
+.P
+If you are sure that your module will \fIdefinitely not\fR run properly on
+versions of Node/npm other than those specified in the \fBengines\fP object,
+then you can set \fB"engineStrict": true\fP in your package\.json file\.
+This will override the user's \fBengine\-strict\fP config setting\.
+.P
+Please do not do this unless you are really very very sure\.  If your
+engines object is something overly restrictive, you can quite easily and
+inadvertently lock yourself into obscurity and prevent your users from
+updating to new versions of Node\.  Consider this choice carefully\.
+.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
+If your package is primarily a command\-line application that should be
+installed globally, then set this value to \fBtrue\fP to provide a warning
+if it is installed locally\.
+.P
+It doesn't actually prevent users from installing it locally, but it
+does help prevent some confusion if it doesn't work as expected\.
+.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 of course 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 7 faq
+.IP \(bu 2
+npm help install
+.IP \(bu 2
+npm help publish
+.IP \(bu 2
+npm help uninstall
+
+.RE
+

node_modules/npm/man/man5/npmrc.5

@@ -0,0 +1,114 @@
+.TH "NPMRC" "5" "March 2017" "" ""
+.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
+.P
+\fBNOTE:\fR Because local (per\-project or per\-user) \fB\|\.npmrc\fP files can contain
+sensitive credentials, they must be readable and writable \fIonly\fR by your user
+account (i\.e\. must have a mode of \fB0600\fP), otherwise they \fIwill be ignored by
+npm!\fR
+.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
+

node_modules/npm/man/man5/package.json.5

@@ -0,0 +1,923 @@
+.TH "PACKAGE\.JSON" "5" "March 2017" "" ""
+.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
+The \fImost\fR important things in your package\.json are the name and version fields\.
+Those are actually required, and your package won't install without
+them\.  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\.
+.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
+The \fImost\fR important things in your package\.json are the name and version fields\.
+Those are actually required, and your package won't install without
+them\.  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\.
+.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
+\fBNOTE\fR: This is \fInot\fR the same as "url"\.  If you put a "url" field,
+then the registry will think it's a redirection to your package that has
+been published somewhere else, and spit at you\.
+.P
+Literally\.  Spit\.  I'm so not kidding\.
+.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://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" : "http://opensource\.org/licenses/ISC"
+  }
+}
+
+// Not valid metadata
+{ "licenses" :
+  [
+    { "type": "MIT"
+    , "url": "http://www\.opensource\.org/licenses/mit\-license\.php"
+    }
+  , { "type": "Apache\-2\.0"
+    , "url": "http://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 "files" field is an array of files to include in your project\.  If
+you name a folder in the array, then it will also include the files
+inside that folder\. (Unless they would be ignored by another rule\.)
+.P
+You can also provide a "\.npmignore" file in the root of your package or
+in subdirectories, which will keep files from being included, even
+if they would be picked up by the files array\.  The \fB\|\.npmignore\fP file
+works just like a \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 (any casing and file extension)
+.IP \(bu 2
+\fBLICENSE\fP / \fBLICENCE\fP
+.IP \(bu 2
+The file in the "main" field
+
+.RE
+.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
+
+.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 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/npm\.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": "gist:11081aaa281"
+
+"repository": "bitbucket:example/repo"
+
+"repository": "gitlab:another/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\-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 can be of the form:
+.P
+.RS 2
+.nf
+git://github\.com/user/project\.git#commit\-ish
+git+ssh://user@hostname:project\.git#commit\-ish
+git+ssh://user@hostname/project\.git#commit\-ish
+git+http://user@hostname/project/blah\.git#commit\-ish
+git+https://user@hostname/project/blah\.git#commit\-ish
+.fi
+.RE
+.P
+The \fBcommit\-ish\fP can be any tag, sha, or branch which can be supplied as
+an argument to \fBgit checkout\fP\|\.  The default is \fBmaster\fP\|\.
+.SH 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": "visionmedia/express",
+    "mocha": "visionmedia/mocha#4727d357ea"
+  }
+}
+.fi
+.RE
+.SH 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 \-\-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 \fBprepublish\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": {
+    "prepublish": "coffee \-o lib/ \-c src/waza\.coffee"
+  },
+  "main": "lib/waza\.js"
+}
+.fi
+.RE
+.P
+The \fBprepublish\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 \fIhttp://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:
+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 will produce warnings when your package is installed as a dependency\.
+.SH engineStrict
+.P
+\fBNOTE: This feature is deprecated and will be removed in npm 3\.0\.0\.\fR
+.P
+If you are sure that your module will \fIdefinitely not\fR run properly on
+versions of Node/npm other than those specified in the \fBengines\fP object,
+then you can set \fB"engineStrict": true\fP in your package\.json file\.
+This will override the user's \fBengine\-strict\fP config setting\.
+.P
+Please do not do this unless you are really very very sure\.  If your
+engines object is something overly restrictive, you can quite easily and
+inadvertently lock yourself into obscurity and prevent your users from
+updating to new versions of Node\.  Consider this choice carefully\.
+.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
+If your package is primarily a command\-line application that should be
+installed globally, then set this value to \fBtrue\fP to provide a warning
+if it is installed locally\.
+.P
+It doesn't actually prevent users from installing it locally, but it
+does help prevent some confusion if it doesn't work as expected\.
+.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 of course 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 7 faq
+.IP \(bu 2
+npm help install
+.IP \(bu 2
+npm help publish
+.IP \(bu 2
+npm help uninstall
+
+.RE
+

node_modules/npm/man/man7/npm-coding-style.7

@@ -0,0 +1,204 @@
+.TH "NPM\-CODING\-STYLE" "7" "March 2017" "" ""
+.SH "NAME"
+\fBnpm-coding-style\fR \- npm's "funny" coding style
+.SH DESCRIPTION
+.P
+npm's coding style is a bit unconventional\.  It is not different for
+difference's sake, but rather a carefully crafted style that is
+designed to reduce visual clutter and make bugs more apparent\.
+.P
+If you want to contribute to npm (which is very encouraged), you should
+make your code conform to npm's style\.
+.P
+Note: this concerns npm's code not the specific packages that you can download from the npm registry\.
+.SH Line Length
+.P
+Keep lines shorter than 80 characters\.  It's better for lines to be
+too short than to be too long\.  Break up long lists, objects, and other
+statements onto multiple lines\.
+.SH Indentation
+.P
+Two\-spaces\.  Tabs are better, but they look like hell in web browsers
+(and on GitHub), and node uses 2 spaces, so that's that\.
+.P
+Configure your editor appropriately\.
+.SH Curly braces
+.P
+Curly braces belong on the same line as the thing that necessitates them\.
+.P
+Bad:
+.P
+.RS 2
+.nf
+function ()
+{
+.fi
+.RE
+.P
+Good:
+.P
+.RS 2
+.nf
+function () {
+.fi
+.RE
+.P
+If a block needs to wrap to the next line, use a curly brace\.  Don't
+use it if it doesn't\.
+.P
+Bad:
+.P
+.RS 2
+.nf
+if (foo) { bar() }
+while (foo)
+  bar()
+.fi
+.RE
+.P
+Good:
+.P
+.RS 2
+.nf
+if (foo) bar()
+while (foo) {
+  bar()
+}
+.fi
+.RE
+.SH Semicolons
+.P
+Don't use them except in four situations:
+.RS 0
+.IP \(bu 2
+\fBfor (;;)\fP loops\.  They're actually required\.
+.IP \(bu 2
+null loops like: \fBwhile (something) ;\fP (But you'd better have a good
+reason for doing that\.)
+.IP \(bu 2
+\fBcase "foo": doSomething(); break\fP
+.IP \(bu 2
+In front of a leading \fB(\fP or \fB[\fP at the start of the line\.
+This prevents the expression from being interpreted
+as a function call or property access, respectively\.
+
+.RE
+.P
+Some examples of good semicolon usage:
+.P
+.RS 2
+.nf
+;(x || y)\.doSomething()
+;[a, b, c]\.forEach(doSomething)
+for (var i = 0; i < 10; i ++) {
+  switch (state) {
+    case "begin": start(); continue
+    case "end": finish(); break
+    default: throw new Error("unknown state")
+  }
+  end()
+}
+.fi
+.RE
+.P
+Note that starting lines with \fB\-\fP and \fB+\fP also should be prefixed
+with a semicolon, but this is much less common\.
+.SH Comma First
+.P
+If there is a list of things separated by commas, and it wraps
+across multiple lines, put the comma at the start of the next
+line, directly below the token that starts the list\.  Put the
+final token in the list on a line by itself\.  For example:
+.P
+.RS 2
+.nf
+var magicWords = [ "abracadabra"
+                 , "gesundheit"
+                 , "ventrilo"
+                 ]
+  , spells = { "fireball" : function () { setOnFire() }
+             , "water" : function () { putOut() }
+             }
+  , a = 1
+  , b = "abc"
+  , etc
+  , somethingElse
+.fi
+.RE
+.SH Whitespace
+.P
+Put a single space in front of ( for anything other than a function call\.
+Also use a single space wherever it makes things more readable\.
+.P
+Don't leave trailing whitespace at the end of lines\.  Don't indent empty
+lines\.  Don't use more spaces than are helpful\.
+.SH Functions
+.P
+Use named functions\.  They make stack traces a lot easier to read\.
+.SH Callbacks, Sync/async Style
+.P
+Use the asynchronous/non\-blocking versions of things as much as possible\.
+It might make more sense for npm to use the synchronous fs APIs, but this
+way, the fs and http and child process stuff all uses the same callback\-passing
+methodology\.
+.P
+The callback should always be the last argument in the list\.  Its first
+argument is the Error or null\.
+.P
+Be very careful never to ever ever throw anything\.  It's worse than useless\.
+Just send the error message back as the first argument to the callback\.
+.SH Errors
+.P
+Always create a new Error object with your message\.  Don't just return a
+string message to the callback\.  Stack traces are handy\.
+.SH Logging
+.P
+Logging is done using the npmlog \fIhttps://github\.com/npm/npmlog\fR
+utility\.
+.P
+Please clean up logs when they are no longer helpful\.  In particular,
+logging the same object over and over again is not helpful\.  Logs should
+report what's happening so that it's easier to track down where a fault
+occurs\.
+.P
+Use appropriate log levels\.  See npm help 7 \fBnpm\-config\fP and search for
+"loglevel"\.
+.SH Case, naming, etc\.
+.P
+Use \fBlowerCamelCase\fP for multiword identifiers when they refer to objects,
+functions, methods, properties, or anything not specified in this section\.
+.P
+Use \fBUpperCamelCase\fP for class names (things that you'd pass to "new")\.
+.P
+Use \fBall\-lower\-hyphen\-css\-case\fP for multiword filenames and config keys\.
+.P
+Use named functions\.  They make stack traces easier to follow\.
+.P
+Use \fBCAPS_SNAKE_CASE\fP for constants, things that should never change
+and are rarely used\.
+.P
+Use a single uppercase letter for function names where the function
+would normally be anonymous, but needs to call itself recursively\.  It
+makes it clear that it's a "throwaway" function\.
+.SH null, undefined, false, 0
+.P
+Boolean variables and functions should always be either \fBtrue\fP or
+\fBfalse\fP\|\.  Don't set it to 0 unless it's supposed to be a number\.
+.P
+When something is intentionally missing or removed, set it to \fBnull\fP\|\.
+.P
+Don't set things to \fBundefined\fP\|\.  Reserve that value to mean "not yet
+set to anything\."
+.P
+Boolean objects are verboten\.
+.SH SEE ALSO
+.RS 0
+.IP \(bu 2
+npm help 7 developers
+.IP \(bu 2
+npm help 7 faq
+.IP \(bu 2
+npm help npm
+
+.RE
+

node_modules/npm/man/man7/npm-developers.7

@@ -0,0 +1,282 @@
+.TH "NPM\-DEVELOPERS" "7" "March 2017" "" ""
+.SH "NAME"
+\fBnpm-developers\fR \- Developer Guide
+.SH DESCRIPTION
+.P
+So, you've decided to use npm to develop (and maybe publish/deploy)
+your project\.
+.P
+Fantastic!
+.P
+There are a few things that you need to do above the simple steps
+that your users will do to install your program\.
+.SH About These Documents
+.P
+These are man pages\.  If you install npm, you should be able to
+then do \fBman npm\-thing\fP to get the documentation on a particular
+topic, or \fBnpm help thing\fP to see the same information\.
+.SH What is a \fBpackage\fP
+.P
+A package is:
+.RS 0
+.IP \(bu 2
+a) a folder containing a program described by a package\.json file
+.IP \(bu 2
+b) a gzipped tarball containing (a)
+.IP \(bu 2
+c) a url that resolves to (b)
+.IP \(bu 2
+d) a \fB<name>@<version>\fP that is published on the registry with (c)
+.IP \(bu 2
+e) a \fB<name>@<tag>\fP that points to (d)
+.IP \(bu 2
+f) a \fB<name>\fP that has a "latest" tag satisfying (e)
+.IP \(bu 2
+g) a \fBgit\fP url that, when cloned, results in (a)\.
+
+.RE
+.P
+Even if you never publish your package, you can still get a lot of
+benefits of using npm if you just want to write a node program (a), and
+perhaps if you also want to be able to easily install it elsewhere
+after packing it up into a tarball (b)\.
+.P
+Git urls can be of the form:
+.P
+.RS 2
+.nf
+git://github\.com/user/project\.git#commit\-ish
+git+ssh://user@hostname:project\.git#commit\-ish
+git+http://user@hostname/project/blah\.git#commit\-ish
+git+https://user@hostname/project/blah\.git#commit\-ish
+.fi
+.RE
+.P
+The \fBcommit\-ish\fP can be any tag, sha, or branch which can be supplied as
+an argument to \fBgit checkout\fP\|\.  The default is \fBmaster\fP\|\.
+.SH The package\.json File
+.P
+You need to have a \fBpackage\.json\fP file in the root of your project to do
+much of anything with npm\.  That is basically the whole interface\.
+.P
+See npm help 5 \fBpackage\.json\fP for details about what goes in that file\.  At the very
+least, you need:
+.RS 0
+.IP \(bu 2
+name:
+This should be a string that identifies your project\.  Please do not
+use the name to specify that it runs on node, or is in JavaScript\.
+You can use the "engines" field to explicitly state the versions of
+node (or whatever else) that your program requires, and it's pretty
+well assumed that it's javascript\.
+It does not necessarily need to match your github repository name\.
+So, \fBnode\-foo\fP and \fBbar\-js\fP are bad names\.  \fBfoo\fP or \fBbar\fP are better\.
+.IP \(bu 2
+version:
+A semver\-compatible version\.
+.IP \(bu 2
+engines:
+Specify the versions of node (or whatever else) that your program
+runs on\.  The node API changes a lot, and there may be bugs or new
+functionality that you depend on\.  Be explicit\.
+.IP \(bu 2
+author:
+Take some credit\.
+.IP \(bu 2
+scripts:
+If you have a special compilation or installation script, then you
+should put it in the \fBscripts\fP object\.  You should definitely have at
+least a basic smoke\-test command as the "scripts\.test" field\.
+See npm help 7 scripts\.
+.IP \(bu 2
+main:
+If you have a single module that serves as the entry point to your
+program (like what the "foo" package gives you at require("foo")),
+then you need to specify that in the "main" field\.
+.IP \(bu 2
+directories:
+This is an object mapping names to folders\.  The best ones to include are
+"lib" and "doc", but if you use "man" to specify a folder full of man pages,
+they'll get installed just like these ones\.
+
+.RE
+.P
+You can use \fBnpm init\fP in the root of your package in order to get you
+started with a pretty basic package\.json file\.  See npm help \fBnpm\-init\fP for
+more info\.
+.SH Keeping files \fIout\fR of your package
+.P
+Use a \fB\|\.npmignore\fP file to keep stuff out of your package\.  If there's
+no \fB\|\.npmignore\fP file, but there \fIis\fR a \fB\|\.gitignore\fP file, then npm will
+ignore the stuff matched by the \fB\|\.gitignore\fP file\.  If you \fIwant\fR to
+include something that is excluded by your \fB\|\.gitignore\fP file, you can
+create an empty \fB\|\.npmignore\fP file to override it\. Like \fBgit\fP, \fBnpm\fP looks
+for \fB\|\.npmignore\fP and \fB\|\.gitignore\fP files in all subdirectories of your
+package, not only the root directory\.
+.P
+\fB\|\.npmignore\fP files follow the same pattern rules \fIhttps://git\-scm\.com/book/en/v2/Git\-Basics\-Recording\-Changes\-to\-the\-Repository#Ignoring\-Files\fR
+as \fB\|\.gitignore\fP files:
+.RS 0
+.IP \(bu 2
+Blank lines or lines starting with \fB#\fP are ignored\.
+.IP \(bu 2
+Standard glob patterns work\.
+.IP \(bu 2
+You can end patterns with a forward slash \fB/\fP to specify a directory\.
+.IP \(bu 2
+You can negate a pattern by starting it with an exclamation point \fB!\fP\|\.
+
+.RE
+.P
+By default, the following paths and files are ignored, so there's no
+need to add them to \fB\|\.npmignore\fP explicitly:
+.RS 0
+.IP \(bu 2
+\fB\|\.*\.swp\fP
+.IP \(bu 2
+\fB\|\._*\fP
+.IP \(bu 2
+\fB\|\.DS_Store\fP
+.IP \(bu 2
+\fB\|\.git\fP
+.IP \(bu 2
+\fB\|\.hg\fP
+.IP \(bu 2
+\fB\|\.npmrc\fP
+.IP \(bu 2
+\fB\|\.lock\-wscript\fP
+.IP \(bu 2
+\fB\|\.svn\fP
+.IP \(bu 2
+\fB\|\.wafpickle\-*\fP
+.IP \(bu 2
+\fBconfig\.gypi\fP
+.IP \(bu 2
+\fBCVS\fP
+.IP \(bu 2
+\fBnpm\-debug\.log\fP
+
+.RE
+.P
+Additionally, everything in \fBnode_modules\fP is ignored, except for
+bundled dependencies\. npm automatically handles this for you, so don't
+bother adding \fBnode_modules\fP to \fB\|\.npmignore\fP\|\.
+.P
+The following paths and files are never ignored, so adding them to
+\fB\|\.npmignore\fP is pointless:
+.RS 0
+.IP \(bu 2
+\fBpackage\.json\fP
+.IP \(bu 2
+\fBREADME\fP (and its variants)
+.IP \(bu 2
+\fBCHANGELOG\fP (and its variants)
+.IP \(bu 2
+\fBLICENSE\fP / \fBLICENCE\fP
+
+.RE
+.SH Link Packages
+.P
+\fBnpm link\fP is designed to install a development package and see the
+changes in real time without having to keep re\-installing it\.  (You do
+need to either re\-link or \fBnpm rebuild \-g\fP to update compiled packages,
+of course\.)
+.P
+More info at npm help \fBnpm\-link\fP\|\.
+.SH Before Publishing: Make Sure Your Package Installs and Works
+.P
+\fBThis is important\.\fR
+.P
+If you can not install it locally, you'll have
+problems trying to publish it\.  Or, worse yet, you'll be able to
+publish it, but you'll be publishing a broken or pointless package\.
+So don't do that\.
+.P
+In the root of your package, do this:
+.P
+.RS 2
+.nf
+npm install \. \-g
+.fi
+.RE
+.P
+That'll show you that it's working\.  If you'd rather just create a symlink
+package that points to your working directory, then do this:
+.P
+.RS 2
+.nf
+npm link
+.fi
+.RE
+.P
+Use \fBnpm ls \-g\fP to see if it's there\.
+.P
+To test a local install, go into some other folder, and then do:
+.P
+.RS 2
+.nf
+cd \.\./some\-other\-folder
+npm install \.\./my\-package
+.fi
+.RE
+.P
+to install it locally into the node_modules folder in that other place\.
+.P
+Then go into the node\-repl, and try using require("my\-thing") to
+bring in your module's main module\.
+.SH Create a User Account
+.P
+Create a user with the adduser command\.  It works like this:
+.P
+.RS 2
+.nf
+npm adduser
+.fi
+.RE
+.P
+and then follow the prompts\.
+.P
+This is documented better in npm help adduser\.
+.SH Publish your package
+.P
+This part's easy\.  In the root of your folder, do this:
+.P
+.RS 2
+.nf
+npm publish
+.fi
+.RE
+.P
+You can give publish a url to a tarball, or a filename of a tarball,
+or a path to a folder\.
+.P
+Note that pretty much \fBeverything in that folder will be exposed\fR
+by default\.  So, if you have secret stuff in there, use a
+\fB\|\.npmignore\fP file to list out the globs to ignore, or publish
+from a fresh checkout\.
+.SH Brag about it
+.P
+Send emails, write blogs, blab in IRC\.
+.P
+Tell the world how easy it is to install your program!
+.SH SEE ALSO
+.RS 0
+.IP \(bu 2
+npm help 7 faq
+.IP \(bu 2
+npm help npm
+.IP \(bu 2
+npm help init
+.IP \(bu 2
+npm help 5 package\.json
+.IP \(bu 2
+npm help 7 scripts
+.IP \(bu 2
+npm help publish
+.IP \(bu 2
+npm help adduser
+.IP \(bu 2
+npm help 7 registry
+
+.RE
+