update packages to latest version

node_modules/npm/doc/api/npm-bin.md

@@ -0,0 +1,13 @@
+npm-bin(3) -- Display npm bin folder
+====================================
+
+## SYNOPSIS
+
+    npm.commands.bin(args, cb)
+
+## DESCRIPTION
+
+Print the folder where npm will install executables.
+
+This function should not be used programmatically.  Instead, just refer
+to the `npm.bin` property.

node_modules/npm/doc/api/npm-bugs.md

@@ -0,0 +1,19 @@
+npm-bugs(3) -- Bugs for a package in a web browser maybe
+========================================================
+
+## SYNOPSIS
+
+    npm.commands.bugs(package, callback)
+
+## DESCRIPTION
+
+This command tries to guess at the likely location of a package's
+bug tracker URL, and then tries to open it using the `--browser`
+config param.
+
+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.
+
+This command will launch a browser, so this command may not be the most
+friendly for programmatic use.

node_modules/npm/doc/api/npm-cache.md

@@ -0,0 +1,30 @@
+npm-cache(3) -- manage the npm cache programmatically
+=====================================================
+
+## SYNOPSIS
+
+    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)
+
+## DESCRIPTION
+
+This acts much the same ways as the npm-cache(1) command line
+functionality.
+
+The callback is called with the package.json data of the thing that is
+eventually added to or read from the cache.
+
+The top level `npm.commands.cache(...)` functionality is a public
+interface, and like all commands on the `npm.commands` object, it will
+match the command line behavior exactly.
+
+However, the cache folder structure and the cache helper functions are
+considered **internal** API surface, and as such, may change in future
+releases of npm, potentially without warning or significant version
+incrementation.
+
+Use at your own risk.

node_modules/npm/doc/api/npm-commands.md

@@ -0,0 +1,22 @@
+npm-commands(3) -- npm commands
+===============================
+
+## SYNOPSIS
+
+    npm.commands[<command>](args, callback)
+
+## DESCRIPTION
+
+npm comes with a full set of commands, and each of the commands takes a
+similar set of arguments.
+
+In general, all commands on the command object take an **array** of positional
+argument **strings**. The last argument to any function is a callback. Some
+commands are special and take other optional arguments.
+
+All commands have their own man page. See `man npm-<command>` for command-line
+usage, or `man 3 npm-<command>` for programmatic usage.
+
+## SEE ALSO
+
+* npm-index(7)

node_modules/npm/doc/api/npm-config.md

@@ -0,0 +1,45 @@
+npm-config(3) -- Manage the npm configuration files
+===================================================
+
+## SYNOPSIS
+
+    npm.commands.config(args, callback)
+    var val = npm.config.get(key)
+    npm.config.set(key, val)
+
+## DESCRIPTION
+
+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:
+
+* `set`
+
+    Sets a config parameter.  The second element in `args` is interpreted as the
+    key, and the third element is interpreted as the value.
+
+* `get`
+
+    Gets the value of a config parameter. The second element in `args` is the
+    key to get the value of.
+
+* `delete` (`rm` or `del`)
+
+    Deletes a parameter from the config. The second element in `args` is the
+    key to delete.
+
+* `list` (`ls`)
+
+    Show all configs that aren't secret. No parameters necessary.
+
+* `edit`:
+
+    Opens the config file in the default editor. This command isn't very useful
+    programmatically, but it is made available.
+
+To programmatically access npm configuration settings, or set them for
+the duration of a program, use the `npm.config.set` and `npm.config.get`
+functions instead.
+
+## SEE ALSO
+
+* npm(3)

node_modules/npm/doc/api/npm-deprecate.md

@@ -0,0 +1,34 @@
+npm-deprecate(3) -- Deprecate a version of a package
+====================================================
+
+## SYNOPSIS
+
+    npm.commands.deprecate(args, callback)
+
+## DESCRIPTION
+
+This command will update the npm registry entry for a package, providing
+a deprecation warning to all who attempt to install it.
+
+The 'args' parameter must have exactly two elements:
+
+* `package[@version]`
+
+    The `version` portion is optional, and may be either a range, or a
+    specific version, or a tag.
+
+* `message`
+
+    The warning message that will be printed whenever a user attempts to
+    install the package.
+
+Note that you must be the package owner to deprecate something.  See the
+`owner` and `adduser` help topics.
+
+To un-deprecate a package, specify an empty string (`""`) for the `message` argument.
+
+## SEE ALSO
+
+* npm-publish(3)
+* npm-unpublish(3)
+* npm-registry(7)

node_modules/npm/doc/api/npm-docs.md

@@ -0,0 +1,19 @@
+npm-docs(3) -- Docs for a package in a web browser maybe
+========================================================
+
+## SYNOPSIS
+
+    npm.commands.docs(package, callback)
+
+## DESCRIPTION
+
+This command tries to guess at the likely location of a package's
+documentation URL, and then tries to open it using the `--browser`
+config param.
+
+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.
+
+This command will launch a browser, so this command may not be the most
+friendly for programmatic use.

node_modules/npm/doc/api/npm-edit.md

@@ -0,0 +1,24 @@
+npm-edit(3) -- Edit an installed package
+========================================
+
+## SYNOPSIS
+
+    npm.commands.edit(package, callback)
+
+## DESCRIPTION
+
+Opens the package folder in the default editor (or whatever you've
+configured as the npm `editor` config -- see `npm help config`.)
+
+After it has been edited, the package is rebuilt so as to pick up any
+changes in compiled packages.
+
+For instance, you can do `npm install connect` to install connect
+into your package, and then `npm.commands.edit(["connect"], callback)`
+to make a few changes to your locally installed copy.
+
+The first parameter is a string array with a single element, the package
+to open. The package can optionally have a version number attached.
+
+Since this command opens an editor in a new process, be careful about where
+and how this is used.

node_modules/npm/doc/api/npm-explore.md

@@ -0,0 +1,18 @@
+npm-explore(3) -- Browse an installed package
+=============================================
+
+## SYNOPSIS
+
+    npm.commands.explore(args, callback)
+
+## DESCRIPTION
+
+Spawn a subshell in the directory of the installed package specified.
+
+If a command is specified, then it is run in the subshell, which then
+immediately terminates.
+
+Note that the package is *not* automatically rebuilt afterwards, so be
+sure to use `npm rebuild <pkg>` if you make any changes.
+
+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/doc/api/npm-help-search.md

@@ -0,0 +1,30 @@
+npm-help-search(3) -- Search the help pages
+===========================================
+
+## SYNOPSIS
+
+    npm.commands.helpSearch(args, [silent,] callback)
+
+## DESCRIPTION
+
+This command is rarely useful, but it exists in the rare case that it is.
+
+This command takes an array of search terms and returns the help pages that
+match in order of best match.
+
+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:
+
+* hits:
+  A map of args to number of hits on that arg. For example, {"npm": 3}
+* found:
+  Total number of unique args that matched.
+* totalHits:
+  Total number of hits.
+* lines:
+  An array of all matching lines (and some adjacent lines).
+* file:
+  Name of the file that matched
+
+The silent parameter is not necessary not used, but it may in the future.

node_modules/npm/doc/api/npm-init.md

@@ -0,0 +1,29 @@
+npm init(3) -- Interactively create a package.json file
+=======================================================
+
+## SYNOPSIS
+
+    npm.commands.init(args, callback)
+
+## DESCRIPTION
+
+This will ask you a bunch of questions, and then write a package.json for you.
+
+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.
+
+If you already have a package.json file, it'll read that first, and default to
+the options in there.
+
+It is strictly additive, so it does not delete options from your package.json
+without a really good reason to do so.
+
+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.
+
+## SEE ALSO
+
+package.json(5)

node_modules/npm/doc/api/npm-install.md

@@ -0,0 +1,19 @@
+npm-install(3) -- install a package programmatically
+====================================================
+
+## SYNOPSIS
+
+    npm.commands.install([where,] packages, callback)
+
+## DESCRIPTION
+
+This acts much the same ways as installing on the command-line.
+
+The 'where' parameter is optional and only used internally, and it specifies
+where the packages should be installed to.
+
+The 'packages' parameter is an array of strings. Each element in the array is
+the name of a package to be installed.
+
+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/doc/api/npm-link.md

@@ -0,0 +1,33 @@
+npm-link(3) -- Symlink a package folder
+=======================================
+
+## SYNOPSIS
+
+    npm.commands.link(callback)
+    npm.commands.link(packages, callback)
+
+## DESCRIPTION
+
+Package linking is a two-step process.
+
+Without parameters, link will create a globally-installed
+symbolic link from `prefix/package-name` to the current folder.
+
+With a parameters, link will create a symlink from the local `node_modules`
+folder to the global symlink.
+
+When creating tarballs for `npm publish`, the linked packages are
+"snapshotted" to their current state by resolving the symbolic links.
+
+This is
+handy for installing your own stuff, so that you can work on it and test it
+iteratively without having to continually rebuild.
+
+For example:
+
+    npm.commands.link(cb)           # creates global link from the cwd
+                                    # (say redis package)
+    npm.commands.link('redis', cb)  # link-install the package
+
+Now, any changes to the redis package will be reflected in
+the package in the current working directory

node_modules/npm/doc/api/npm-load.md

@@ -0,0 +1,26 @@
+npm-load(3) -- Load config settings
+===================================
+
+## SYNOPSIS
+
+    npm.load(conf, cb)
+
+## DESCRIPTION
+
+npm.load() must be called before any other function call.  Both parameters are
+optional, but the second is recommended.
+
+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.
+
+The first parameter should follow a similar structure as the package.json
+config object.
+
+For example, to emulate the --dev flag, pass an object that looks like this:
+
+    {
+      "dev": true
+    }
+
+For a list of all the available command-line configs, see `npm help config`

node_modules/npm/doc/api/npm-ls.md

@@ -0,0 +1,56 @@
+npm-ls(3) -- List installed packages
+======================================
+
+## SYNOPSIS
+
+    npm.commands.ls(args, [silent,] callback)
+
+## DESCRIPTION
+
+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.
+
+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 `global` to list global packages.
+
+It will print out extraneous, missing, and invalid packages.
+
+If the silent parameter is set to true, nothing will be output to the screen,
+but the data will still be returned.
+
+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.
+
+## CONFIGURATION
+
+### long
+
+* Default: false
+* Type: Boolean
+
+Show extended information.
+
+### parseable
+
+* Default: false
+* Type: Boolean
+
+Show parseable output instead of tree view.
+
+### global
+
+* Default: false
+* Type: Boolean
+
+List packages in the global install prefix instead of in the current
+project.
+
+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/doc/api/npm-outdated.md

@@ -0,0 +1,13 @@
+npm-outdated(3) -- Check for outdated packages
+==============================================
+
+## SYNOPSIS
+
+    npm.commands.outdated([packages,] callback)
+
+## DESCRIPTION
+
+This command will check the registry to see if the specified packages are
+currently outdated.
+
+If the 'packages' parameter is left out, npm will check all packages.

node_modules/npm/doc/api/npm-owner.md

@@ -0,0 +1,31 @@
+npm-owner(3) -- Manage package owners
+=====================================
+
+## SYNOPSIS
+
+    npm.commands.owner(args, callback)
+
+## DESCRIPTION
+
+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):
+
+* 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.
+* 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.
+* rm (user, package):
+  Remove a user from the package owner list.  This immediately revokes their
+  privileges.
+
+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.
+
+## SEE ALSO
+
+* npm-publish(3)
+* npm-registry(7)

node_modules/npm/doc/api/npm-pack.md

@@ -0,0 +1,19 @@
+npm-pack(3) -- Create a tarball from a package
+==============================================
+
+## SYNOPSIS
+
+    npm.commands.pack([packages,] callback)
+
+## DESCRIPTION
+
+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 `<name>-<version>.tgz`, and then write the filenames out to
+stdout.
+
+If the same package is specified multiple times, then the file will be
+overwritten the second time.
+
+If no arguments are supplied, then npm packs the current package folder.

node_modules/npm/doc/api/npm-ping.md

@@ -0,0 +1,14 @@
+npm-ping(3) -- Ping npm registry
+================================
+
+## SYNOPSIS
+
+    npm.registry.ping(registry, options, function (er, pong))
+
+## DESCRIPTION
+
+Attempts to connect to the given registry, returning a `pong`
+object with various metadata if it succeeds.
+
+This function is primarily useful for debugging connection issues
+to npm registries.

node_modules/npm/doc/api/npm-prefix.md

@@ -0,0 +1,15 @@
+npm-prefix(3) -- Display prefix
+===============================
+
+## SYNOPSIS
+
+    npm.commands.prefix(args, callback)
+
+## DESCRIPTION
+
+Print the prefix to standard out.
+
+'args' is never used and callback is never called with data.
+'args' must be present or things will break.
+
+This function is not useful programmatically

node_modules/npm/doc/api/npm-prune.md

@@ -0,0 +1,17 @@
+npm-prune(3) -- Remove extraneous packages
+==========================================
+
+## SYNOPSIS
+
+    npm.commands.prune([packages,] callback)
+
+## DESCRIPTION
+
+This command removes "extraneous" packages.
+
+The first parameter is optional, and it specifies packages to be removed.
+
+No packages are specified, then all packages will be checked.
+
+Extraneous packages are packages that are not listed on the parent
+package's dependencies list.

node_modules/npm/doc/api/npm-publish.md

@@ -0,0 +1,30 @@
+npm-publish(3) -- Publish a package
+===================================
+
+## SYNOPSIS
+
+    npm.commands.publish([packages,] callback)
+
+## DESCRIPTION
+
+Publishes a package to the registry so that it can be installed by name.
+Possible values in the 'packages' array are:
+
+* `<folder>`:
+  A folder containing a package.json file
+
+* `<tarball>`:
+  A url or file path to a gzipped tar archive containing a single folder
+  with a package.json file inside.
+
+If the package array is empty, npm will try to publish something in the
+current working directory.
+
+This command could fails if one of the packages specified already exists in
+the registry.  Overwrites when the "force" environment variable is set.
+
+## SEE ALSO
+
+* npm-registry(7)
+* npm-adduser(1)
+* npm-owner(3)

node_modules/npm/doc/api/npm-rebuild.md

@@ -0,0 +1,16 @@
+npm-rebuild(3) -- Rebuild a package
+===================================
+
+## SYNOPSIS
+
+    npm.commands.rebuild([packages,] callback)
+
+## DESCRIPTION
+
+This command runs the `npm build` 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.
+
+## CONFIGURATION
+
+See `npm help build`

node_modules/npm/doc/api/npm-repo.md

@@ -0,0 +1,19 @@
+npm-repo(3) -- Open package repository page in the browser
+========================================================
+
+## SYNOPSIS
+
+    npm.commands.repo(package, callback)
+
+## DESCRIPTION
+
+This command tries to guess at the likely location of a package's
+repository URL, and then tries to open it using the `--browser`
+config param.
+
+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.
+
+This command will launch a browser, so this command may not be the most
+friendly for programmatic use.

node_modules/npm/doc/api/npm-restart.md

@@ -0,0 +1,41 @@
+npm-restart(3) -- Restart a package
+===================================
+
+## SYNOPSIS
+
+    npm.commands.restart(packages, callback)
+
+## DESCRIPTION
+
+This restarts a package (or multiple packages).
+
+This runs a package's "stop", "restart", and "start" scripts, and associated
+pre- and post- scripts, in the order given below:
+
+1. prerestart
+2. prestop
+3. stop
+4. poststop
+5. restart
+6. prestart
+7. start
+8. poststart
+9. postrestart
+
+If no version is specified, then it restarts the "active" version.
+
+npm can restart multiple packages. Just specify multiple packages in
+the `packages` parameter.
+
+## NOTE
+
+Note that the "restart" script is run **in addition to** the "stop"
+and "start" scripts, not instead of them.
+
+This is the behavior as of `npm` major version 2.  A change in this
+behavior will be accompanied by an increase in major version number
+
+## SEE ALSO
+
+* npm-start(3)
+* npm-stop(3)

node_modules/npm/doc/api/npm-root.md

@@ -0,0 +1,15 @@
+npm-root(3) -- Display npm root
+===============================
+
+## SYNOPSIS
+
+    npm.commands.root(args, callback)
+
+## DESCRIPTION
+
+Print the effective `node_modules` folder to standard out.
+
+'args' is never used and callback is never called with data.
+'args' must be present or things will break.
+
+This function is not useful programmatically.

node_modules/npm/doc/api/npm-run-script.md

@@ -0,0 +1,27 @@
+npm-run-script(3) -- Run arbitrary package scripts
+==================================================
+
+## SYNOPSIS
+
+    npm.commands.run-script(args, callback)
+
+## DESCRIPTION
+
+This runs an arbitrary command from a package's "scripts" object.
+
+It is used by the test, start, restart, and stop commands, but can be
+called directly, as well.
+
+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.
+
+## SEE ALSO
+
+* npm-scripts(7)
+* npm-test(3)
+* npm-start(3)
+* npm-restart(3)
+* npm-stop(3)

node_modules/npm/doc/api/npm-search.md

@@ -0,0 +1,35 @@
+npm-search(3) -- Search for packages
+====================================
+
+## SYNOPSIS
+
+    npm.commands.search(searchTerms, [silent,] [staleness,] callback)
+
+## DESCRIPTION
+
+Search the registry for packages matching the search terms. The available parameters are:
+
+* searchTerms:
+  Array of search terms. These terms are case-insensitive.
+* silent:
+  If true, npm will not log anything to the console.
+* staleness:
+  This is the threshold for stale packages. "Fresh" packages are not refreshed
+  from the registry. This value is measured in seconds.
+* 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:
+
+    * name
+    * description
+    * maintainers
+    * url
+    * keywords
+
+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/doc/api/npm-shrinkwrap.md

@@ -0,0 +1,20 @@
+npm-shrinkwrap(3) -- programmatically generate package shrinkwrap file
+====================================================
+
+## SYNOPSIS
+
+    npm.commands.shrinkwrap(args, [silent,] callback)
+
+## DESCRIPTION
+
+This acts much the same ways as shrinkwrapping on the command-line.
+
+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.
+
+If the 'silent' parameter is set to true, nothing will be output to the screen,
+but the shrinkwrap file will still be written.
+
+Finally, 'callback' is a function that will be called when the shrinkwrap has
+been saved.

node_modules/npm/doc/api/npm-start.md

@@ -0,0 +1,13 @@
+npm-start(3) -- Start a package
+===============================
+
+## SYNOPSIS
+
+    npm.commands.start(packages, callback)
+
+## DESCRIPTION
+
+This runs a package's "start" script, if one was provided.
+
+npm can start multiple packages. Just specify multiple packages in the
+`packages` parameter.

node_modules/npm/doc/api/npm-stop.md

@@ -0,0 +1,13 @@
+npm-stop(3) -- Stop a package
+=============================
+
+## SYNOPSIS
+
+    npm.commands.stop(packages, callback)
+
+## DESCRIPTION
+
+This runs a package's "stop" script, if one was provided.
+
+npm can run stop on multiple packages. Just specify multiple packages
+in the `packages` parameter.

node_modules/npm/doc/api/npm-tag.md

@@ -0,0 +1,23 @@
+npm-tag(3) -- Tag a published version
+=====================================
+
+## SYNOPSIS
+
+    npm.commands.tag(package@version, tag, callback)
+
+## DESCRIPTION
+
+Tags the specified version of the package with the specified tag, or the
+`--tag` config if not specified.
+
+The 'package@version' is an array of strings, but only the first two elements are
+currently used.
+
+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).
+
+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
+`man 3 npm-config` for programmatic usage or `man npm-config` for cli usage.

node_modules/npm/doc/api/npm-test.md

@@ -0,0 +1,16 @@
+npm-test(3) -- Test a package
+=============================
+
+## SYNOPSIS
+
+      npm.commands.test(packages, callback)
+
+## DESCRIPTION
+
+This runs a package's "test" script, if one was provided.
+
+To run tests as a condition of installation, set the `npat` config to
+true.
+
+npm can run tests on multiple packages. Just specify multiple packages
+in the `packages` parameter.

node_modules/npm/doc/api/npm-uninstall.md

@@ -0,0 +1,16 @@
+npm-uninstall(3) -- uninstall a package programmatically
+========================================================
+
+## SYNOPSIS
+
+    npm.commands.uninstall(packages, callback)
+
+## DESCRIPTION
+
+This acts much the same ways as uninstalling on the command-line.
+
+The 'packages' parameter is an array of strings. Each element in the array is
+the name of a package to be uninstalled.
+
+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/doc/api/npm-unpublish.md

@@ -0,0 +1,20 @@
+npm-unpublish(3) -- Remove a package from the registry
+======================================================
+
+## SYNOPSIS
+
+    npm.commands.unpublish(package, callback)
+
+## DESCRIPTION
+
+This removes a package version from the registry, deleting its
+entry and removing the tarball.
+
+The package parameter must be defined.
+
+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.
+
+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/doc/api/npm-update.md

@@ -0,0 +1,18 @@
+npm-update(3) -- Update a package
+=================================
+
+## SYNOPSIS
+
+    npm.commands.update(packages, callback)
+
+# DESCRIPTION
+
+Updates a package, upgrading it to the latest version. It also installs any
+missing packages.
+
+The `packages` argument is an array of packages to update. The `callback`
+parameter will be called when done or when an error occurs.
+
+## SEE ALSO
+
+* npm-update(1)

node_modules/npm/doc/api/npm-version.md

@@ -0,0 +1,18 @@
+npm-version(3) -- Bump a package version
+========================================
+
+## SYNOPSIS
+
+    npm.commands.version(newversion, callback)
+
+## DESCRIPTION
+
+Run this in a package directory to bump the version and write the new
+data back to the package.json file.
+
+If run in a git repo, it will also create a version commit and tag, and
+fail if the repo is not clean.
+
+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/doc/api/npm-view.md

@@ -0,0 +1,93 @@
+npm-view(3) -- View registry info
+=================================
+
+## SYNOPSIS
+
+    npm.commands.view(args, [silent,] callback)
+
+## DESCRIPTION
+
+This command shows data about a package and prints it to the stream
+referenced by the `outfd` config, which defaults to stdout.
+
+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.
+
+The callback will be passed all of the data returned by the query.
+
+For example, to get the package registry entry for the `connect` package,
+you can do this:
+
+    npm.commands.view(["connect"], callback)
+
+If no version is specified, "latest" is assumed.
+
+Field names can be specified after the package descriptor.
+For example, to show the dependencies of the `ronn` package at version
+0.3.5, you could do the following:
+
+    npm.commands.view(["ronn@0.3.5", "dependencies"], callback)
+
+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:
+
+    npm.commands.view(["npm", "repository.url"], callback)
+
+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:
+
+    npm.commands.view(["express", "contributors.email"], callback)
+
+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:
+
+    npm.commands.view(["express", "contributors[0].email"], callback)
+
+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:
+
+    npm.commands.view(["express", "contributors.name", "contributors.email"], callback)
+
+"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 json` for more on this.)
+
+    npm.commands.view(["npm", "contributors"], callback)
+
+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:
+
+    npm.commands.view(["yui3@>0.5.4", "dependencies.jsdom"], callback)
+
+## OUTPUT
+
+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 version range matches multiple versions, than each printed value
+will be prefixed with the version it applies to.
+
+If multiple fields are requested, than each of them are prefixed with
+the field name.
+
+Console output can be disabled by setting the 'silent' parameter to true.
+
+## RETURN VALUE
+
+The data returned will be an object in this formation:
+
+    { <version>:
+      { <field>: <value>
+      , ... }
+    , ... }
+
+corresponding to the list of fields selected.

node_modules/npm/doc/api/npm-whoami.md

@@ -0,0 +1,15 @@
+npm-whoami(3) -- Display npm username
+=====================================
+
+## SYNOPSIS
+
+    npm.commands.whoami(args, callback)
+
+## DESCRIPTION
+
+Print the `username` config to standard output.
+
+'args' is never used and callback is never called with data.
+'args' must be present or things will break.
+
+This function is not useful programmatically

node_modules/npm/doc/api/npm.md

@@ -0,0 +1,115 @@
+npm(3) -- javascript package manager
+====================================
+
+## SYNOPSIS
+
+    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)
+    })
+
+## VERSION
+
+@VERSION@
+
+## DESCRIPTION
+
+This is the API documentation for npm.
+To find documentation of the command line
+client, see `npm(1)`.
+
+Prior to using npm's commands, `npm.load()` must be called.  If you provide
+`configObject` 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-config(1)`, `npm-config(7)`, and `npmrc(5)` for more information.
+
+After that, each of the functions are accessible in the
+commands object: `npm.commands.<cmd>`.  See `npm-index(7)` for a list of
+all possible commands.
+
+All commands on the command object take an **array** of positional argument
+**strings**. The last argument to any function is a callback. Some
+commands take other optional arguments.
+
+Configs cannot currently be set on a per function basis, as each call to
+npm.config.set will change the value for *all* npm commands in that process.
+
+To find API documentation for a specific command, run the `npm apihelp`
+command.
+
+## METHODS AND PROPERTIES
+
+* `npm.load(configs, cb)`
+
+    Load the configuration params, and call the `cb` function once the
+    globalconfig and userconfig files have been loaded as well, or on
+    nextTick if they've already been loaded.
+
+* `npm.config`
+
+    An object for accessing npm configuration parameters.
+
+    * `npm.config.get(key)`
+    * `npm.config.set(key, val)`
+    * `npm.config.del(key)`
+
+* `npm.dir` or `npm.root`
+
+    The `node_modules` directory where npm will operate.
+
+* `npm.prefix`
+
+    The prefix where npm is operating.  (Most often the current working
+    directory.)
+
+* `npm.cache`
+
+    The place where npm keeps JSON and tarballs it fetches from the
+    registry (or uploads to the registry).
+
+* `npm.tmp`
+
+    npm's temporary working directory.
+
+* `npm.deref`
+
+    Get the "real" name for a command that has either an alias or
+    abbreviation.
+
+## MAGIC
+
+For each of the methods in the `npm.commands` object, a method is added to the
+npm object, which takes a set of positional string arguments rather than an
+array and a callback.
+
+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.
+
+For example, this would work in a node repl:
+
+    > npm = require("npm")
+    > npm.load()  // wait a sec...
+    > npm.install("dnode", "express")
+
+Note that that *won't* work in a node program, since the `install`
+method will get called before the configuration load is completed.
+
+## ABBREVS
+
+In order to support `npm ins foo` instead of `npm install foo`, the
+`npm.commands` object has a set of abbreviations as well as the full
+method names.  Use the `npm.deref` method to find the real name.
+
+For example:
+
+    var cmd = npm.deref("unp") // cmd === "unpublish"

node_modules/npm/doc/cli/npm-access.md

@@ -0,0 +1,74 @@
+npm-access(1) -- Set access level on published packages
+=======================================================
+
+## SYNOPSIS
+
+    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>]
+
+## DESCRIPTION
+
+Used to set access controls on private packages.
+
+For all of the subcommands, `npm access` will perform actions on the packages
+in the current working directory if no package name is passed to the
+subcommand.
+
+* public / restricted:
+  Set a package to be either publicly accessible or restricted.
+
+* grant / revoke:
+  Add or remove the ability of users and teams to have read-only or read-write
+  access to a package.
+
+* 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)
+
+* 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 `<user>` is passed in,
+  the list is filtered only to teams _that_ user happens to belong to.
+
+* edit:
+  Set the access privileges for a package at once using `$EDITOR`.
+
+## DETAILS
+
+`npm access` always operates directly on the current registry, configurable
+from the command line using `--registry=<registry url>`.
+
+Unscoped packages are *always public*.
+
+Scoped packages *default to restricted*, but you can either publish them as
+public using `npm publish --access=public`, or set their access as public using
+`npm access public` after the initial publish.
+
+You must have privileges to set the access of a package:
+
+* You are an owner of an unscoped or scoped package.
+* You are a member of the team that owns a scope.
+* You have been given read-write privileges for a package, either as a member
+  of a team or directly as an owner.
+
+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
+`--access=public`.
+
+Management of teams and team memberships is done with the `npm team` command.
+
+## SEE ALSO
+
+* npm-team(1)
+* npm-publish(1)
+* npm-config(7)
+* npm-registry(7)

node_modules/npm/doc/cli/npm-adduser.md

@@ -0,0 +1,75 @@
+npm-adduser(1) -- Add a registry user account
+=============================================
+
+## SYNOPSIS
+
+    npm adduser [--registry=url] [--scope=@orgname] [--always-auth]
+
+    aliases: login, add-user
+
+## DESCRIPTION
+
+Create or verify a user named `<username>` in the specified registry, and
+save the credentials to the `.npmrc` file. If no registry is specified,
+the default registry will be used (see `npm-config(7)`).
+
+The username, password, and email are read in from prompts.
+
+To reset your password, go to <https://www.npmjs.com/forgot>
+
+To change your email address, go to <https://www.npmjs.com/email-edit>
+
+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.
+
+`npm login` is an alias to `adduser` and behaves exactly the same way.
+
+## CONFIGURATION
+
+### registry
+
+Default: https://registry.npmjs.org/
+
+The base URL of the npm package registry. If `scope` is also specified,
+this registry will only be used for packages with that scope. See `npm-scope(7)`.
+
+### scope
+
+Default: none
+
+If specified, the user and login credentials given will be associated
+with the specified scope. See `npm-scope(7)`. You can use both at the same time,
+e.g.
+
+    npm adduser --registry=http://myregistry.example.com --scope=@myco
+
+This will set a registry for the given scope and login or create a user for
+that registry at the same time.
+
+### always-auth
+
+Default: false
+
+If specified, save configuration indicating that all requests to the given
+registry should include authorization information. Useful for private
+registries. Can be used with `--registry` and / or `--scope`, e.g.
+
+    npm adduser --registry=http://private-registry.example.com --always-auth
+
+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 `always-auth` in `npm-config(7)` for more details on
+always-auth. Registry-specific configuration of `always-auth` takes precedence
+over any global configuration.
+
+## SEE ALSO
+
+* npm-registry(7)
+* npm-config(1)
+* npm-config(7)
+* npmrc(5)
+* npm-owner(1)
+* npm-whoami(1)

node_modules/npm/doc/cli/npm-bin.md

@@ -0,0 +1,19 @@
+npm-bin(1) -- Display npm bin folder
+====================================
+
+## SYNOPSIS
+
+    npm bin
+
+## DESCRIPTION
+
+Print the folder where npm will install executables.
+
+## SEE ALSO
+
+* npm-prefix(1)
+* npm-root(1)
+* npm-folders(5)
+* npm-config(1)
+* npm-config(7)
+* npmrc(5)

node_modules/npm/doc/cli/npm-bugs.md

@@ -0,0 +1,44 @@
+npm-bugs(1) -- Bugs for a package in a web browser maybe
+========================================================
+
+## SYNOPSIS
+
+    npm bugs <pkgname>
+    npm bugs (with no args in a package dir)
+
+    aliases: issues
+
+## DESCRIPTION
+
+This command tries to guess at the likely location of a package's
+bug tracker URL, and then tries to open it using the `--browser`
+config param. If no package name is provided, it will search for
+a `package.json` in the current folder and use the `name` property.
+
+## CONFIGURATION
+
+### browser
+
+* Default: OS X: `"open"`, Windows: `"start"`, Others: `"xdg-open"`
+* Type: String
+
+The browser that is called by the `npm bugs` command to open websites.
+
+### registry
+
+* Default: https://registry.npmjs.org/
+* Type: url
+
+The base URL of the npm package registry.
+
+
+## SEE ALSO
+
+* npm-docs(1)
+* npm-view(1)
+* npm-publish(1)
+* npm-registry(7)
+* npm-config(1)
+* npm-config(7)
+* npmrc(5)
+* package.json(5)

node_modules/npm/doc/cli/npm-build.md

@@ -0,0 +1,25 @@
+npm-build(1) -- Build a package
+===============================
+
+## SYNOPSIS
+
+    npm build <package-folder>
+
+* `<package-folder>`:
+  A folder containing a `package.json` file in its root.
+
+## DESCRIPTION
+
+This is the plumbing command called by `npm link` and `npm install`.
+
+It should generally be called during installation, but if you need to run it
+directly, run:
+
+    npm run-script build
+
+## SEE ALSO
+
+* npm-install(1)
+* npm-link(1)
+* npm-scripts(7)
+* package.json(5)

node_modules/npm/doc/cli/npm-bundle.md

@@ -0,0 +1,14 @@
+npm-bundle(1) -- REMOVED
+========================
+
+## DESCRIPTION
+
+The `npm bundle` 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.
+
+Just use `npm install` now to do what `npm bundle` used to do.
+
+## SEE ALSO
+
+* npm-install(1)

node_modules/npm/doc/cli/npm-cache.md

@@ -0,0 +1,70 @@
+npm-cache(1) -- Manipulates packages cache
+==========================================
+
+## SYNOPSIS
+
+    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>]
+
+## DESCRIPTION
+
+Used to add, list, or clear the npm cache folder.
+
+* 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.
+
+* ls:
+  Show the data in the cache.  Argument is a path to show in the cache
+  folder.  Works a bit like the `find` program, but limited by the
+  `depth` config.
+
+* 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.
+
+## DETAILS
+
+npm stores cache data in the directory specified in `npm config get cache`.
+For each package that is added to the cache, three pieces of information are
+stored in `{cache}/{name}/{version}`:
+
+* .../package/package.json:
+  The package.json file, as npm sees it.
+* .../package.tgz:
+  The tarball for that version.
+
+Additionally, whenever a registry request is made, a `.cache.json` file
+is placed at the corresponding URI, to store the ETag and the requested
+data.  This is stored in `{cache}/{hostname}/{path}/.cache.json`.
+
+Commands that make non-essential registry requests (such as `search` and
+`view`, or the completion scripts) generally specify a minimum timeout.
+If the `.cache.json` file is younger than the specified timeout, then
+they do not make an HTTP request to the registry.
+
+## CONFIGURATION
+
+### cache
+
+Default: `~/.npm` on Posix, or `%AppData%/npm-cache` on Windows.
+
+The root cache folder.
+
+## SEE ALSO
+
+* npm-folders(5)
+* npm-config(1)
+* npm-config(7)
+* npmrc(5)
+* npm-install(1)
+* npm-publish(1)
+* npm-pack(1)

node_modules/npm/doc/cli/npm-completion.md

@@ -0,0 +1,29 @@
+npm-completion(1) -- Tab Completion for npm
+===========================================
+
+## SYNOPSIS
+
+    . <(npm completion)
+
+## DESCRIPTION
+
+Enables tab-completion in all npm commands.
+
+The synopsis above
+loads the completions into your current shell.  Adding it to
+your ~/.bashrc or ~/.zshrc will make the completions available
+everywhere.
+
+You may of course also pipe the output of npm completion to a file
+such as `/usr/local/etc/bash_completion.d/npm` if you have a system
+that will read that file for you.
+
+When `COMP_CWORD`, `COMP_LINE`, and `COMP_POINT` are defined in the
+environment, `npm completion` acts in "plumbing mode", and outputs
+completions based on the arguments.
+
+## SEE ALSO
+
+* npm-developers(7)
+* npm-faq(7)
+* npm(1)

node_modules/npm/doc/cli/npm-config.md

@@ -0,0 +1,73 @@
+npm-config(1) -- Manage the npm configuration files
+===================================================
+
+## SYNOPSIS
+
+    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
+
+## DESCRIPTION
+
+npm gets its config settings from the command line, environment
+variables, `npmrc` files, and in some cases, the `package.json` file.
+
+See npmrc(5) for more information about the npmrc files.
+
+See `npm-config(7)` for a more thorough discussion of the mechanisms
+involved.
+
+The `npm config` command can be used to update and edit the contents
+of the user and global npmrc files.
+
+## Sub-commands
+
+Config supports the following sub-commands:
+
+### set
+
+    npm config set key value
+
+Sets the config key to the value.
+
+If value is omitted, then it sets it to "true".
+
+### get
+
+    npm config get key
+
+Echo the config value to stdout.
+
+### list
+
+    npm config list
+
+Show all the config settings.
+
+### delete
+
+    npm config delete key
+
+Deletes the key from all configuration files.
+
+### edit
+
+    npm config edit
+
+Opens the config file in an editor.  Use the `--global` flag to edit the
+global config.
+
+## SEE ALSO
+
+* npm-folders(5)
+* npm-config(7)
+* package.json(5)
+* npmrc(5)
+* npm(1)

node_modules/npm/doc/cli/npm-dedupe.md

@@ -0,0 +1,60 @@
+npm-dedupe(1) -- Reduce duplication
+===================================
+
+## SYNOPSIS
+
+    npm dedupe [package names...]
+    npm ddp [package names...]
+
+    aliases: find-dupes, ddp
+
+## DESCRIPTION
+
+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.
+
+For example, consider this dependency graph:
+
+    a
+    +-- b <-- depends on c@1.0.x
+    |   `-- c@1.0.3
+    `-- d <-- depends on c@~1.0.9
+        `-- c@1.0.10
+
+In this case, `npm-dedupe(1)` will transform the tree to:
+
+    a
+    +-- b
+    +-- d
+    `-- c@1.0.10
+
+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.
+
+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.
+
+If no suitable version can be found, then a warning is printed, and
+nothing is done.
+
+If any arguments are supplied, then they are filters, and only the
+named packages will be touched.
+
+Note that this operation transforms the dependency tree, and may
+result in packages getting updated versions, perhaps from the npm
+registry.
+
+This feature is experimental, and may change in future versions.
+
+The `--tag` 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.
+
+## SEE ALSO
+
+* npm-ls(1)
+* npm-update(1)
+* npm-install(1)

node_modules/npm/doc/cli/npm-deprecate.md

@@ -0,0 +1,26 @@
+npm-deprecate(1) -- Deprecate a version of a package
+====================================================
+
+## SYNOPSIS
+
+    npm deprecate <name>[@<version>] <message>
+
+## DESCRIPTION
+
+This command will update the npm registry entry for a package, providing
+a deprecation warning to all who attempt to install it.
+
+It works on version ranges as well as specific versions, so you can do
+something like this:
+
+    npm deprecate my-thing@"< 0.2.3" "critical bug fixed in v0.2.3"
+
+Note that you must be the package owner to deprecate something.  See the
+`owner` and `adduser` help topics.
+
+To un-deprecate a package, specify an empty string (`""`) for the `message` argument.
+
+## SEE ALSO
+
+* npm-publish(1)
+* npm-registry(7)

node_modules/npm/doc/cli/npm-dist-tag.md

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

node_modules/npm/doc/cli/npm-docs.md

@@ -0,0 +1,44 @@
+npm-docs(1) -- Docs for a package in a web browser maybe
+========================================================
+
+## SYNOPSIS
+
+    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)
+
+## DESCRIPTION
+
+This command tries to guess at the likely location of a package's
+documentation URL, and then tries to open it using the `--browser`
+config param. You can pass multiple package names at once. If no
+package name is provided, it will search for a `package.json` in
+the current folder and use the `name` property.
+
+## CONFIGURATION
+
+### browser
+
+* Default: OS X: `"open"`, Windows: `"start"`, Others: `"xdg-open"`
+* Type: String
+
+The browser that is called by the `npm docs` command to open websites.
+
+### registry
+
+* Default: https://registry.npmjs.org/
+* Type: url
+
+The base URL of the npm package registry.
+
+
+## SEE ALSO
+
+* npm-view(1)
+* npm-publish(1)
+* npm-registry(7)
+* npm-config(1)
+* npm-config(7)
+* npmrc(5)
+* package.json(5)

node_modules/npm/doc/cli/npm-edit.md

@@ -0,0 +1,37 @@
+npm-edit(1) -- Edit an installed package
+========================================
+
+## SYNOPSIS
+
+    npm edit <name>[@<version>]
+
+## DESCRIPTION
+
+Opens the package folder in the default editor (or whatever you've
+configured as the npm `editor` config -- see `npm-config(7)`.)
+
+After it has been edited, the package is rebuilt so as to pick up any
+changes in compiled packages.
+
+For instance, you can do `npm install connect` to install connect
+into your package, and then `npm edit connect` to make a few
+changes to your locally installed copy.
+
+## CONFIGURATION
+
+### editor
+
+* Default: `EDITOR` environment variable if set, or `"vi"` on Posix,
+  or `"notepad"` on Windows.
+* Type: path
+
+The command to run for `npm edit` or `npm config edit`.
+
+## SEE ALSO
+
+* npm-folders(5)
+* npm-explore(1)
+* npm-install(1)
+* npm-config(1)
+* npm-config(7)
+* npmrc(5)

node_modules/npm/doc/cli/npm-explore.md

@@ -0,0 +1,39 @@
+npm-explore(1) -- Browse an installed package
+=============================================
+
+## SYNOPSIS
+
+    npm explore <name> [ -- <cmd>]
+
+## DESCRIPTION
+
+Spawn a subshell in the directory of the installed package specified.
+
+If a command is specified, then it is run in the subshell, which then
+immediately terminates.
+
+This is particularly handy in the case of git submodules in the
+`node_modules` folder:
+
+    npm explore some-dependency -- git pull origin master
+
+Note that the package is *not* automatically rebuilt afterwards, so be
+sure to use `npm rebuild <pkg>` if you make any changes.
+
+## CONFIGURATION
+
+### shell
+
+* Default: SHELL environment variable, or "bash" on Posix, or "cmd" on
+  Windows
+* Type: path
+
+The shell to run for the `npm explore` command.
+
+## SEE ALSO
+
+* npm-folders(5)
+* npm-edit(1)
+* npm-rebuild(1)
+* npm-build(1)
+* npm-install(1)

node_modules/npm/doc/cli/npm-help-search.md

@@ -0,0 +1,35 @@
+npm-help-search(1) -- Search npm help documentation
+===================================================
+
+## SYNOPSIS
+
+    npm help-search some search terms
+
+## DESCRIPTION
+
+This command will search the npm markdown documentation files for the
+terms provided, and then list the results, sorted by relevance.
+
+If only one result is found, then it will show that help topic.
+
+If the argument to `npm help` is not a known help topic, then it will
+call `help-search`.  It is rarely if ever necessary to call this
+command directly.
+
+## CONFIGURATION
+
+### long
+
+* Type: Boolean
+* Default: false
+
+If true, the "long" flag will cause help-search to output context around
+where the terms were found in the documentation.
+
+If false, then help-search will just list out the help topics found.
+
+## SEE ALSO
+
+* npm(1)
+* npm-faq(7)
+* npm-help(1)

node_modules/npm/doc/cli/npm-help.md

@@ -0,0 +1,40 @@
+npm-help(1) -- Get help on npm
+==============================
+
+## SYNOPSIS
+
+    npm help <topic>
+    npm help some search terms
+
+## DESCRIPTION
+
+If supplied a topic, then show the appropriate documentation page.
+
+If the topic does not exist, or if multiple terms are provided, then run
+the `help-search` command to find a match.  Note that, if `help-search`
+finds a single subject, then it will run `help` on that topic, so unique
+matches are equivalent to specifying a topic name.
+
+## CONFIGURATION
+
+### viewer
+
+* Default: "man" on Posix, "browser" on Windows
+* Type: path
+
+The program to use to view help content.
+
+Set to `"browser"` to view html help content in the default web browser.
+
+## SEE ALSO
+
+* npm(1)
+* README
+* npm-faq(7)
+* npm-folders(5)
+* npm-config(1)
+* npm-config(7)
+* npmrc(5)
+* package.json(5)
+* npm-help-search(1)
+* npm-index(7)

node_modules/npm/doc/cli/npm-init.md

@@ -0,0 +1,38 @@
+npm-init(1) -- Interactively create a package.json file
+=======================================================
+
+## SYNOPSIS
+
+    npm init [-f|--force|-y|--yes]
+
+## DESCRIPTION
+
+This will ask you a bunch of questions, and then write a package.json for you.
+
+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.
+
+If you already have a package.json file, it'll read that first, and default to
+the options in there.
+
+It is strictly additive, so it does not delete options from your package.json
+without a really good reason to do so.
+
+If you invoke it with `-f`, `--force`, `-y`, or `--yes`, it will use only
+defaults and not prompt you for any options.
+
+## CONFIGURATION
+
+### scope
+
+* Default: none
+* Type: String
+
+The scope under which the new module should be created.
+
+## SEE ALSO
+
+* <https://github.com/isaacs/init-package-json>
+* package.json(5)
+* npm-version(1)
+* npm-scope(7)

node_modules/npm/doc/cli/npm-install.md

@@ -0,0 +1,339 @@
+npm-install(1) -- Install a package
+===================================
+
+## SYNOPSIS
+
+    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)
+
+## DESCRIPTION
+
+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-shrinkwrap(1).
+
+A `package` is:
+
+* a) a folder containing a program described by a `package.json(5)` file
+* b) a gzipped tarball containing (a)
+* c) a url that resolves to (b)
+* d) a `<name>@<version>` that is published on the registry (see `npm-registry(7)`) with (c)
+* e) a `<name>@<tag>` (see `npm-dist-tag(1)`) that points to (d)
+* f) a `<name>` that has a "latest" tag satisfying (e)
+* g) a `<git remote url>` that resolves to (b)
+
+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).
+
+
+* `npm install` (in package directory, no arguments):
+
+    Install the dependencies in the local node_modules folder.
+
+    In global mode (ie, with `-g` or `--global` appended to the command),
+    it installs the current package context (ie, the current working
+    directory) as a global package.
+
+    By default, `npm install` will install all modules listed as dependencies
+    in `package.json(5)`.
+
+    With the `--production` flag (or when the `NODE_ENV` environment variable
+    is set to `production`), npm will not install modules listed in
+    `devDependencies`.
+
+* `npm install <folder>`:
+
+    Install a package that is sitting in a folder on the filesystem.
+
+* `npm install <tarball file>`:
+
+    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 `npm link`.
+
+    Example:
+
+          npm install ./package.tgz
+
+* `npm install <tarball url>`:
+
+    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:
+
+          npm install https://github.com/indexzero/forever/tarball/v0.5.6
+
+* `npm install [@<scope>/]<name> [--save|--save-dev|--save-optional]`:
+
+    Do a `<name>@<tag>` install, where `<tag>` is the "tag" config. (See
+    `npm-config(7)`. The config's default value is `latest`.)
+
+    In most cases, this will install the latest version
+    of the module published on npm.
+
+    Example:
+
+          npm install sax
+
+    `npm install` takes 3 exclusive, optional flags which save or update
+    the package version in your main package.json:
+
+    * `--save`: Package will appear in your `dependencies`.
+
+    * `--save-dev`: Package will appear in your `devDependencies`.
+
+    * `--save-optional`: Package will appear in your `optionalDependencies`.
+
+    When using any of the above options to save dependencies to your
+    package.json, there are two additional, optional flags:
+
+    * `--save-exact`: Saved dependencies will be configured with an
+      exact version rather than using npm's default semver range
+      operator.
+
+    * `-B, --save-bundle`: Saved dependencies will also be added to your `bundleDependencies` 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:
+
+          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
+
+
+    **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.
+
+* `npm install [@<scope>/]<name>@<tag>`:
+
+    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:
+
+          npm install sax@latest
+          npm install @myorg/mypackage@latest
+
+* `npm install [@<scope>/]<name>@<version>`:
+
+    Install the specified version of the package.  This will fail if the
+    version has not been published to the registry.
+
+    Example:
+
+          npm install sax@0.1.1
+          npm install @myorg/privatepackage@1.5.0
+
+* `npm install [@<scope>/]<name>@<version range>`:
+
+    Install a version of the package matching the specified version range.  This
+    will follow the same rules for resolving dependencies described in `package.json(5)`.
+
+    Note that most version ranges must be put in quotes so that your shell will
+    treat it as a single argument.
+
+    Example:
+
+          npm install sax@">=0.1.0 <0.2.0"
+          npm install @myorg/privatepackage@">=0.1.0 <0.2.0"
+
+* `npm install <git remote url>`:
+
+    Install a package by cloning a git remote url.  The format of the git
+    url is:
+
+          <protocol>://[<user>[:<password>]@]<hostname>[:<port>][:/]<path>[#<commit-ish>]
+
+    `<protocol>` is one of `git`, `git+ssh`, `git+http`, or
+    `git+https`.  If no `<commit-ish>` is specified, then `master` is
+    used.
+
+    The following git environment variables are recognized by npm and will be added
+    to the environment when running git:
+
+    * `GIT_ASKPASS`
+    * `GIT_EXEC_PATH`
+    * `GIT_PROXY_COMMAND`
+    * `GIT_SSH`
+    * `GIT_SSH_COMMAND`
+    * `GIT_SSL_CAINFO`
+    * `GIT_SSL_NO_VERIFY`
+
+    See the git man page for details.
+
+    Examples:
+
+          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
+
+* `npm install <githubname>/<githubrepo>[#<commit-ish>]`:
+* `npm install github:<githubname>/<githubrepo>[#<commit-ish>]`:
+
+    Install the package at `https://github.com/githubname/githubrepo` by
+    attempting to clone it using `git`.
+
+    If you don't specify a *commit-ish* then `master` will be used.
+
+    Examples:
+
+          npm install mygithubuser/myproject
+          npm install github:mygithubuser/myproject
+
+* `npm install gist:[<githubname>/]<gistID>[#<commit-ish>]`:
+
+    Install the package at `https://gist.github.com/gistID` by attempting to
+    clone it using `git`. The GitHub username associated with the gist is
+    optional and will not be saved in `package.json` if `--save` is used.
+
+    If you don't specify a *commit-ish* then `master` will be used.
+
+    Example:
+
+          npm install gist:101a11beef
+
+* `npm install bitbucket:<bitbucketname>/<bitbucketrepo>[#<commit-ish>]`:
+
+    Install the package at `https://bitbucket.org/bitbucketname/bitbucketrepo`
+    by attempting to clone it using `git`.
+
+    If you don't specify a *commit-ish* then `master` will be used.
+
+    Example:
+
+          npm install bitbucket:mybitbucketuser/myproject
+
+* `npm install gitlab:<gitlabname>/<gitlabrepo>[#<commit-ish>]`:
+
+    Install the package at `https://gitlab.com/gitlabname/gitlabrepo`
+    by attempting to clone it using `git`.
+
+    If you don't specify a *commit-ish* then `master` will be used.
+
+    Example:
+
+          npm install gitlab:mygitlabuser/myproject
+
+You may combine multiple arguments, and even multiple types of arguments.
+For example:
+
+    npm install sax@">=0.1.0 <0.2.0" bench supervisor
+
+The `--tag` 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.
+
+The `--force` argument will force npm to fetch remote resources even if a
+local copy exists on disk.
+
+    npm install sax --force
+
+The `--global` argument will cause npm to install the package globally
+rather than locally.  See `npm-folders(5)`.
+
+The `--ignore-scripts` argument will cause npm to not execute any
+scripts defined in the package.json. See `npm-scripts(7)`.
+
+The `--link` argument will cause npm to link global installs into the
+local space in some cases.
+
+The `--no-bin-links` argument will prevent npm from creating symlinks for
+any binaries the package might contain.
+
+The `--no-optional` argument will prevent optional dependencies from
+being installed.
+
+The `--no-shrinkwrap` argument, which will ignore an available
+shrinkwrap file and use the package.json instead.
+
+The `--nodedir=/path/to/node/source` argument will allow npm to find the
+node source code so that npm can compile native modules.
+
+See `npm-config(7)`.  Many of the configuration params have some
+effect on installation, since that's most of what npm does.
+
+## ALGORITHM
+
+To install a package, npm uses the following algorithm:
+
+    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)
+
+For this `package{dep}` structure: `A{B,C}, B{C}, C{D}`,
+this algorithm produces:
+
+    A
+    +-- B
+    `-- C
+        `-- D
+
+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.
+
+See npm-folders(5) for a more detailed description of the specific
+folder structures that npm creates.
+
+### Limitations of npm's Install Algorithm
+
+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:
+
+    A -> B -> A' -> B' -> A -> B -> A' -> B' -> A -> ...
+
+where `A` is some version of a package, and `A'` is a different version
+of the same package.  Because `B` depends on a different version of `A`
+than the one that is already in the tree, it must install a separate
+copy.  The same is true of `A'`, which must install `B'`.  Because `B'`
+depends on the original version of `A`, which has been overridden, the
+cycle falls into infinite regress.
+
+To avoid this situation, npm flat-out refuses to install any
+`name@version` 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.
+
+## SEE ALSO
+
+* npm-folders(5)
+* npm-update(1)
+* npm-link(1)
+* npm-rebuild(1)
+* npm-scripts(7)
+* npm-build(1)
+* npm-config(1)
+* npm-config(7)
+* npmrc(5)
+* npm-registry(7)
+* npm-tag(1)
+* npm-uninstall(1)
+* npm-shrinkwrap(1)
+* package.json(5)

node_modules/npm/doc/cli/npm-link.md

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

node_modules/npm/doc/cli/npm-logout.md

@@ -0,0 +1,45 @@
+npm-logout(1) -- Log out of the registry
+========================================
+
+## SYNOPSIS
+
+    npm logout [--registry=url] [--scope=@orgname]
+
+## DESCRIPTION
+
+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.
+
+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 _only_ affect
+the current environment.
+
+If `--scope` is provided, this will find the credentials for the registry
+connected to that scope, if set.
+
+## CONFIGURATION
+
+### registry
+
+Default: https://registry.npmjs.org/
+
+The base URL of the npm package registry. If `scope` is also specified,
+it takes precedence.
+
+### scope
+
+Default: none
+
+If specified, you will be logged out of the specified scope. See `npm-scope(7)`.
+
+    npm logout --scope=@myco
+
+## SEE ALSO
+
+* npm-adduser(1)
+* npm-registry(7)
+* npm-config(1)
+* npm-config(7)
+* npmrc(5)
+* npm-whoami(1)

node_modules/npm/doc/cli/npm-ls.md

@@ -0,0 +1,94 @@
+npm-ls(1) -- List installed packages
+======================================
+
+## SYNOPSIS
+
+    npm list [[@<scope>/]<pkg> ...]
+    npm ls [[@<scope>/]<pkg> ...]
+    npm la [[@<scope>/]<pkg> ...]
+    npm ll [[@<scope>/]<pkg> ...]
+
+## DESCRIPTION
+
+This command will print to stdout all the versions of packages that are
+installed, as well as their dependencies, in a tree-structure.
+
+Positional arguments are `name@version-range` identifiers, which will
+limit the results to only the paths to the packages named.  Note that
+nested packages will *also* show the paths to the specified packages.
+For example, running `npm ls promzard` in npm's source tree will show:
+
+    npm@@VERSION@ /path/to/npm
+    └─┬ init-package-json@0.0.4
+      └── promzard@0.1.5
+
+It will print out extraneous, missing, and invalid packages.
+
+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.
+
+When run as `ll` or `la`, it shows extended information by default.
+
+## CONFIGURATION
+
+### json
+
+* Default: false
+* Type: Boolean
+
+Show information in JSON format.
+
+### long
+
+* Default: false
+* Type: Boolean
+
+Show extended information.
+
+### parseable
+
+* Default: false
+* Type: Boolean
+
+Show parseable output instead of tree view.
+
+### global
+
+* Default: false
+* Type: Boolean
+
+List packages in the global install prefix instead of in the current
+project.
+
+### depth
+
+* Type: Int
+
+Max display depth of the dependency tree.
+
+### prod / production
+
+* Type: Boolean
+* Default: false
+
+Display only the dependency tree for packages in `dependencies`.
+
+### dev
+
+* Type: Boolean
+* Default: false
+
+Display only the dependency tree for packages in `devDependencies`.
+
+## SEE ALSO
+
+* npm-config(1)
+* npm-config(7)
+* npmrc(5)
+* npm-folders(5)
+* npm-install(1)
+* npm-link(1)
+* npm-prune(1)
+* npm-outdated(1)
+* npm-update(1)

node_modules/npm/doc/cli/npm-outdated.md

@@ -0,0 +1,112 @@
+npm-outdated(1) -- Check for outdated packages
+==============================================
+
+## SYNOPSIS
+
+    npm outdated [<name> [<name> ...]]
+
+## DESCRIPTION
+
+This command will check the registry to see if any (or, specific) installed
+packages are currently outdated.
+
+In the output:
+
+* `wanted` is the maximum version of the package that satisfies the semver
+  range specified in `package.json`. If there's no available semver range (i.e.
+  you're running `npm outdated --global`, or the package isn't included in
+  `package.json`), then `wanted` shows the currently-installed version.
+* `latest` is the version of the package tagged as latest in the registry.
+  Running `npm publish` with no special configuration will publish the package
+  with a dist-tag of `latest`. 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 dist-tag(1).
+* `location` is where in the dependency tree the package is located. Note that
+  `npm outdated` defaults to a depth of 0, so unless you override that, you'll
+  always be seeing only top-level dependencies that are outdated.
+* `package type` (when using `--long` / `-l`) tells you whether this package is
+  a `dependency` or a `devDependency`. Packages not included in `package.json`
+  are always marked `dependencies`.
+
+### An example
+
+```
+$ 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
+```
+
+With these `dependencies`:
+```json
+{
+  "glob": "^5.0.15",
+  "nothingness": "github:othiym23/nothingness#master",
+  "npm": "^3.5.1",
+  "once": "^1.3.1"
+}
+```
+
+A few things to note:
+
+* `glob` requires `^5`, which prevents npm from installing `glob@6`, which is
+  outside the semver range.
+* 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 `npm outdated` and
+  `npm update` 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.
+* `npm@3.5.2` is marked as "wanted", but "latest" is `npm@3.5.1` because npm
+  uses dist-tags to manage its `latest` and `next` release channels. `npm update`
+  will install the _newest_ version, but `npm install npm` (with no semver range)
+  will install whatever's tagged as `latest`.
+* `once` is just plain out of date. Reinstalling `node_modules` from scratch or
+  running `npm update` will bring it up to spec.
+
+## CONFIGURATION
+
+### json
+
+* Default: false
+* Type: Boolean
+
+Show information in JSON format.
+
+### long
+
+* Default: false
+* Type: Boolean
+
+Show extended information.
+
+### parseable
+
+* Default: false
+* Type: Boolean
+
+Show parseable output instead of tree view.
+
+### global
+
+* Default: false
+* Type: Boolean
+
+Check packages in the global install prefix instead of in the current
+project.
+
+### depth
+
+* Default: 0
+* Type: Int
+
+Max depth for checking dependency tree.
+
+## SEE ALSO
+
+* npm-update(1)
+* npm-dist-tag(1)
+* npm-registry(7)
+* npm-folders(5)

node_modules/npm/doc/cli/npm-owner.md

@@ -0,0 +1,35 @@
+npm-owner(1) -- Manage package owners
+=====================================
+
+## SYNOPSIS
+
+    npm owner ls <package name>
+    npm owner add <user> <package name>
+    npm owner rm <user> <package name>
+
+    aliases: author
+
+## DESCRIPTION
+
+Manage ownership of published packages.
+
+* 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.
+* 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.
+* rm:
+  Remove a user from the package owner list.  This immediately revokes their
+  privileges.
+
+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.
+
+## SEE ALSO
+
+* npm-publish(1)
+* npm-registry(7)
+* npm-adduser(1)
+* npm-disputes(7)

node_modules/npm/doc/cli/npm-pack.md

@@ -0,0 +1,27 @@
+npm-pack(1) -- Create a tarball from a package
+==============================================
+
+## SYNOPSIS
+
+    npm pack [<pkg> [<pkg> ...]]
+
+## DESCRIPTION
+
+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 `<name>-<version>.tgz`, and then write the filenames out to
+stdout.
+
+If the same package is specified multiple times, then the file will be
+overwritten the second time.
+
+If no arguments are supplied, then npm packs the current package folder.
+
+## SEE ALSO
+
+* npm-cache(1)
+* npm-publish(1)
+* npm-config(1)
+* npm-config(7)
+* npmrc(5)

node_modules/npm/doc/cli/npm-ping.md

@@ -0,0 +1,16 @@
+npm-ping(1) -- Ping npm registry
+================================
+
+## SYNOPSIS
+
+    npm ping [--registry <registry>]
+
+## DESCRIPTION
+
+Ping the configured or given npm registry and verify authentication.
+
+## SEE ALSO
+
+* npm-config(1)
+* npm-config(7)
+* npmrc(5)

node_modules/npm/doc/cli/npm-prefix.md

@@ -0,0 +1,23 @@
+npm-prefix(1) -- Display prefix
+===============================
+
+## SYNOPSIS
+
+    npm prefix [-g]
+
+## DESCRIPTION
+
+Print the local prefix to standard out. This is the closest parent directory
+to contain a package.json file unless `-g` is also specified.
+
+If `-g` is specified, this will be the value of the global prefix. See
+`npm-config(7)` for more detail.
+
+## SEE ALSO
+
+* npm-root(1)
+* npm-bin(1)
+* npm-folders(5)
+* npm-config(1)
+* npm-config(7)
+* npmrc(5)

node_modules/npm/doc/cli/npm-prune.md

@@ -0,0 +1,27 @@
+npm-prune(1) -- Remove extraneous packages
+==========================================
+
+## SYNOPSIS
+
+    npm prune [<name> [<name ...]]
+    npm prune [<name> [<name ...]] [--production]
+
+## DESCRIPTION
+
+This command removes "extraneous" packages.  If a package name is
+provided, then only packages matching one of the supplied names are
+removed.
+
+Extraneous packages are packages that are not listed on the parent
+package's dependencies list.
+
+If the `--production` flag is specified or the `NODE_ENV` environment
+variable is set to `production`, this command will remove the packages
+specified in your `devDependencies`. Setting `--production=false` will
+negate `NODE_ENV` being set to `production`.
+
+## SEE ALSO
+
+* npm-uninstall(1)
+* npm-folders(5)
+* npm-ls(1)

node_modules/npm/doc/cli/npm-publish.md

@@ -0,0 +1,55 @@
+npm-publish(1) -- Publish a package
+===================================
+
+
+## SYNOPSIS
+
+    npm publish <tarball> [--tag <tag>] [--access <public|restricted>]
+    npm publish <folder> [--tag <tag>] [--access <public|restricted>]
+
+## DESCRIPTION
+
+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 `.gitignore` or
+`.npmignore` file is present. See `npm-developers(7)` for full details on
+what's included in the published package, as well as details on how the package
+is built.
+
+By default npm will publish to the public registry. This can be overridden by
+specifying a different default registry or using a `npm-scope(7)` in the name
+(see `package.json(5)`).
+
+* `<folder>`:
+  A folder containing a package.json file
+
+* `<tarball>`:
+  A url or file path to a gzipped tar archive containing a single folder
+  with a package.json file inside.
+
+* `[--tag <tag>]`
+  Registers the published package with the given tag, such that `npm install
+  <name>@<tag>` will install this version.  By default, `npm publish` updates
+  and `npm install` installs the `latest` tag. See `npm-dist-tag(1)` for
+  details about tags.
+
+* `[--access <public|restricted>]`
+  Tells the registry whether this package should be published as public or
+  restricted. Only applies to scoped packages, which default to `restricted`.
+  If you don't have a paid account, you must publish with `--access public`
+  to publish scoped packages.
+
+Fails if the package name and version combination already exists in
+the specified registry.
+
+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-unpublish(1).
+
+## SEE ALSO
+
+* npm-registry(7)
+* npm-scope(7)
+* npm-adduser(1)
+* npm-owner(1)
+* npm-deprecate(1)
+* npm-tag(1)

node_modules/npm/doc/cli/npm-rebuild.md

@@ -0,0 +1,21 @@
+npm-rebuild(1) -- Rebuild a package
+===================================
+
+## SYNOPSIS
+
+    npm rebuild [<name> [<name> ...]]
+    npm rb [<name> [<name> ...]]
+
+* `<name>`:
+  The package to rebuild
+
+## DESCRIPTION
+
+This command runs the `npm build` 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.
+
+## SEE ALSO
+
+* npm-build(1)
+* npm-install(1)

node_modules/npm/doc/cli/npm-repo.md

@@ -0,0 +1,28 @@
+npm-repo(1) -- Open package repository page in the browser
+========================================================
+
+## SYNOPSIS
+
+    npm repo <pkgname>
+    npm repo (with no args in a package dir)
+
+## DESCRIPTION
+
+This command tries to guess at the likely location of a package's
+repository URL, and then tries to open it using the `--browser`
+config param. If no package name is provided, it will search for
+a `package.json` in the current folder and use the `name` property.
+
+## CONFIGURATION
+
+### browser
+
+* Default: OS X: `"open"`, Windows: `"start"`, Others: `"xdg-open"`
+* Type: String
+
+The browser that is called by the `npm repo` command to open websites.
+
+## SEE ALSO
+
+* npm-docs(1)
+* npm-config(1)

node_modules/npm/doc/cli/npm-restart.md

@@ -0,0 +1,40 @@
+npm-restart(1) -- Restart a package
+===================================
+
+## SYNOPSIS
+
+    npm restart [-- <args>]
+
+## DESCRIPTION
+
+This restarts a package.
+
+This runs a package's "stop", "restart", and "start" scripts, and associated
+pre- and post- scripts, in the order given below:
+
+1. prerestart
+2. prestop
+3. stop
+4. poststop
+5. restart
+6. prestart
+7. start
+8. poststart
+9. postrestart
+
+## NOTE
+
+Note that the "restart" script is run **in addition to** the "stop"
+and "start" scripts, not instead of them.
+
+This is the behavior as of `npm` major version 2.  A change in this
+behavior will be accompanied by an increase in major version number
+
+## SEE ALSO
+
+* npm-run-script(1)
+* npm-scripts(7)
+* npm-test(1)
+* npm-start(1)
+* npm-stop(1)
+* npm-restart(3)

node_modules/npm/doc/cli/npm-rm.md

@@ -0,0 +1,23 @@
+npm-rm(1) -- Remove a package
+=============================
+
+## SYNOPSIS
+
+    npm rm <name>
+    npm r <name>
+    npm uninstall <name>
+    npm un <name>
+
+## DESCRIPTION
+
+This uninstalls a package, completely removing everything npm installed
+on its behalf.
+
+## SEE ALSO
+
+* npm-prune(1)
+* npm-install(1)
+* npm-folders(5)
+* npm-config(1)
+* npm-config(7)
+* npmrc(5)

node_modules/npm/doc/cli/npm-root.md

@@ -0,0 +1,19 @@
+npm-root(1) -- Display npm root
+===============================
+
+## SYNOPSIS
+
+    npm root
+
+## DESCRIPTION
+
+Print the effective `node_modules` folder to standard out.
+
+## SEE ALSO
+
+* npm-prefix(1)
+* npm-bin(1)
+* npm-folders(5)
+* npm-config(1)
+* npm-config(7)
+* npmrc(5)

node_modules/npm/doc/cli/npm-run-script.md

@@ -0,0 +1,48 @@
+npm-run-script(1) -- Run arbitrary package scripts
+==================================================
+
+## SYNOPSIS
+
+    npm run-script [command] [-- <args>]
+    npm run [command] [-- <args>]
+
+## DESCRIPTION
+
+This runs an arbitrary command from a package's `"scripts"` object.  If no
+`"command"` is provided, it will list the available scripts.  `run[-script]` 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.
+
+As of [`npm@2.0.0`](http://blog.npmjs.org/post/98131109725/npm-2-0-0), you can
+use custom arguments when executing scripts. The special option `--` is used by
+[getopt](http://goo.gl/KxMmtG) to delimit the end of the options. npm will pass
+all the arguments after the `--` directly to your script:
+
+    npm run test -- --grep="pattern"
+
+The arguments will only be passed to the script specified after ```npm run```
+and not to any pre or post script.
+
+The `env` 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.
+
+In addition to the shell's pre-existing `PATH`, `npm run` adds
+`node_modules/.bin` to the `PATH` provided to scripts. Any binaries provided by
+locally-installed dependencies can be used without the `node_modules/.bin`
+prefix. For example, if there is a `devDependency` on `tap` in your package,
+you should write:
+
+    "scripts": {"test": "tap test/\*.js"}
+
+instead of `"scripts": {"test": "node_modules/.bin/tap test/\*.js"}` to run your tests.
+
+## SEE ALSO
+
+* npm-scripts(7)
+* npm-test(1)
+* npm-start(1)
+* npm-restart(1)
+* npm-stop(1)

node_modules/npm/doc/cli/npm-search.md

@@ -0,0 +1,45 @@
+npm-search(1) -- Search for packages
+====================================
+
+## SYNOPSIS
+
+    npm search [-l|--long] [search terms ...]
+
+    aliases: s, se, find
+
+## DESCRIPTION
+
+Search the registry for packages matching the search terms.
+
+If a term starts with `/`, then it's interpreted as a regular expression.
+A trailing `/` will be ignored in this case.  (Note that many regular
+expression characters must be escaped or quoted in most shells.)
+
+## CONFIGURATION
+
+### long
+
+* Default: false
+* Type: Boolean
+
+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.
+
+### registry
+
+ * Default: https://registry.npmjs.org/
+ * Type   : url
+
+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, `npm search` will default to that registry when searching.
+Pass a different registry url such as the default above in order to override this setting.
+
+## SEE ALSO
+
+* npm-registry(7)
+* npm-config(1)
+* npm-config(7)
+* npmrc(5)
+* npm-view(1)

node_modules/npm/doc/cli/npm-shrinkwrap.md

@@ -0,0 +1,180 @@
+npm-shrinkwrap(1) -- Lock down dependency versions
+=====================================================
+
+## SYNOPSIS
+
+    npm shrinkwrap
+
+## DESCRIPTION
+
+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 `package.json` file is still
+required if you want to use `npm install`.
+
+By default, `npm install` recursively installs the target's
+dependencies (as specified in `package.json`), 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 `package.json` 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.
+
+As an example, consider package A:
+
+    {
+      "name": "A",
+      "version": "0.1.0",
+      "dependencies": {
+        "B": "<0.1.0"
+      }
+    }
+
+package B:
+
+    {
+      "name": "B",
+      "version": "0.0.1",
+      "dependencies": {
+        "C": "<0.1.0"
+      }
+    }
+
+and package C:
+
+    {
+      "name": "C",
+      "version": "0.0.1"
+    }
+
+If these are the only versions of A, B, and C available in the
+registry, then a normal `npm install A` will install:
+
+    A@0.1.0
+    `-- B@0.0.1
+        `-- C@0.0.1
+
+However, if B@0.0.2 is published, then a fresh `npm install A` will
+install:
+
+    A@0.1.0
+    `-- B@0.0.2
+        `-- C@0.0.1
+
+assuming the new version did not modify B's dependencies. Of course,
+the new version of B could include a new version of C and any number
+of new dependencies. If such changes are undesirable, the author of A
+could specify a dependency on B@0.0.1. However, if A's author and B's
+author are not the same person, there's no way for A's author to say
+that he or she does not want to pull in newly published versions of C
+when B hasn't changed at all.
+
+In this case, A's author can run
+
+    npm shrinkwrap
+
+This generates `npm-shrinkwrap.json`, which will look something like this:
+
+    {
+      "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"
+            }
+          }
+        }
+      }
+    }
+
+The shrinkwrap command has locked down the dependencies based on
+what's currently installed in node_modules.  When `npm install`
+installs a package with an `npm-shrinkwrap.json` in the package
+root, the shrinkwrap file (rather than `package.json` 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 `package.json`
+files.
+
+
+### Using shrinkwrapped packages
+
+Using a shrinkwrapped package is no different than using any other
+package: you can `npm install` it by hand, or add a dependency to your
+`package.json` file and `npm install` it.
+
+### Building shrinkwrapped packages
+
+To shrinkwrap an existing package:
+
+1. Run `npm install` in the package root to install the current
+   versions of all dependencies.
+2. Validate that the package works as expected with these versions.
+3. Run `npm shrinkwrap`, add `npm-shrinkwrap.json` to git, and publish
+   your package.
+
+To add or update a dependency in a shrinkwrapped package:
+
+1. Run `npm install` in the package root to install the current
+   versions of all dependencies.
+2. Add or update dependencies. `npm install` each new or updated
+   package individually and then update `package.json`.  Note that they
+   must be explicitly named in order to be installed: running `npm
+   install` with no arguments will merely reproduce the existing
+   shrinkwrap.
+3. Validate that the package works as expected with the new
+   dependencies.
+4. Run `npm shrinkwrap`, commit the new `npm-shrinkwrap.json`, and
+   publish your package.
+
+You can use npm-outdated(1) to view dependencies with newer versions
+available.
+
+### Other Notes
+
+A shrinkwrap file must be consistent with the package's `package.json`
+file. `npm shrinkwrap` 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 `package.json`), since that would
+indicate that `package.json` is not correct.
+
+Since `npm shrinkwrap` is intended to lock down your dependencies for
+production use, `devDependencies` will not be included unless you
+explicitly set the `--dev` flag when you run `npm shrinkwrap`.  If
+installed `devDependencies` 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 `dependencies` instead.
+
+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.
+
+### Caveats
+
+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.
+
+## SEE ALSO
+
+* npm-install(1)
+* package.json(5)
+* npm-ls(1)

node_modules/npm/doc/cli/npm-star.md

@@ -0,0 +1,22 @@
+npm-star(1) -- Mark your favorite packages
+==========================================
+
+## SYNOPSIS
+
+    npm star <pkgname> [<pkg>, ...]
+    npm unstar <pkgname> [<pkg>, ...]
+
+## DESCRIPTION
+
+"Starring" a package means that you have some interest in it.  It's
+a vaguely positive way to show that you care.
+
+"Unstarring" is the same thing, but in reverse.
+
+It's a boolean thing.  Starring repeatedly has no additional effect.
+
+## SEE ALSO
+
+* npm-view(1)
+* npm-whoami(1)
+* npm-adduser(1)

node_modules/npm/doc/cli/npm-stars.md

@@ -0,0 +1,22 @@
+npm-stars(1) -- View packages marked as favorites
+=================================================
+
+## SYNOPSIS
+
+    npm stars
+    npm stars [username]
+
+## DESCRIPTION
+
+If you have starred a lot of neat things and want to find them again
+quickly this command lets you do just that.
+
+You may also want to see your friend's favorite packages, in this case
+you will most certainly enjoy this command.
+
+## SEE ALSO
+
+* npm-star(1)
+* npm-view(1)
+* npm-whoami(1)
+* npm-adduser(1)

node_modules/npm/doc/cli/npm-start.md

@@ -0,0 +1,24 @@
+npm-start(1) -- Start a package
+===============================
+
+## SYNOPSIS
+
+    npm start [-- <args>]
+
+## DESCRIPTION
+
+This runs an arbitrary command specified in the package's `"start"` property of
+its `"scripts"` object. If no `"start"` property is specified on the
+`"scripts"` object, it will run `node server.js`.
+
+As of [`npm@2.0.0`](http://blog.npmjs.org/post/98131109725/npm-2-0-0), you can
+use custom arguments when executing scripts. Refer to npm-run-script(1) for
+more details.
+
+## SEE ALSO
+
+* npm-run-script(1)
+* npm-scripts(7)
+* npm-test(1)
+* npm-restart(1)
+* npm-stop(1)

node_modules/npm/doc/cli/npm-stop.md

@@ -0,0 +1,18 @@
+npm-stop(1) -- Stop a package
+=============================
+
+## SYNOPSIS
+
+    npm stop [-- <args>]
+
+## DESCRIPTION
+
+This runs a package's "stop" script, if one was provided.
+
+## SEE ALSO
+
+* npm-run-script(1)
+* npm-scripts(7)
+* npm-test(1)
+* npm-start(1)
+* npm-restart(1)

node_modules/npm/doc/cli/npm-tag.md

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

node_modules/npm/doc/cli/npm-team.md

@@ -0,0 +1,55 @@
+npm-team(1) -- Manage organization teams and team memberships
+=============================================================
+
+## SYNOPSIS
+
+    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>
+
+## DESCRIPTION
+
+Used to manage teams in organizations, and change team memberships. Does not
+handle permissions for packages.
+
+Teams must always be fully qualified with the organization/scope they belond to
+when operating on them, separated by a colon (`:`). That is, if you have a
+`developers` team on a `foo` organization, you must always refer to that team as
+`foo:developers` in these commands.
+
+* create / destroy:
+  Create a new team, or destroy an existing one.
+
+* add / rm:
+  Add a user to an existing team, or remove a user from a team they belong to.
+
+* 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.
+
+## DETAILS
+
+`npm team` always operates directly on the current registry, configurable from
+the command line using `--registry=<registry url>`.
+
+In order to create teams and manage team membership, you must be a *team admin*
+under the given organization. Listing teams and team memberships may be done by
+any member of the organizations.
+
+Organization creation and management of team admins and *organization* members
+is done through the website, not the npm CLI.
+
+To use teams to manage permissions on packages belonging to your organization,
+use the `npm access` command to grant or revoke the appropriate permissions.
+
+## SEE ALSO
+
+* npm-access(1)
+* npm-registr(7)

node_modules/npm/doc/cli/npm-test.md

@@ -0,0 +1,23 @@
+npm-test(1) -- Test a package
+=============================
+
+## SYNOPSIS
+
+      npm test [-- <args>]
+
+      aliases: t, tst
+
+## DESCRIPTION
+
+This runs a package's "test" script, if one was provided.
+
+To run tests as a condition of installation, set the `npat` config to
+true.
+
+## SEE ALSO
+
+* npm-run-script(1)
+* npm-scripts(7)
+* npm-start(1)
+* npm-restart(1)
+* npm-stop(1)

node_modules/npm/doc/cli/npm-uninstall.md

@@ -0,0 +1,46 @@
+npm-uninstall(1) -- Remove a package
+=============================
+
+## SYNOPSIS
+
+    npm uninstall [@<scope>/]<package> [--save|--save-dev|--save-optional]
+    npm rm (with any of the previous argument usage)
+
+## DESCRIPTION
+
+This uninstalls a package, completely removing everything npm installed
+on its behalf.
+
+Example:
+
+    npm uninstall sax
+
+In global mode (ie, with `-g` or `--global` appended to the command),
+it uninstalls the current package context as a global package.
+
+`npm uninstall` takes 3 exclusive, optional flags which save or update
+the package version in your main package.json:
+
+* `--save`: Package will be removed from your `dependencies`.
+
+* `--save-dev`: Package will be removed from your `devDependencies`.
+
+* `--save-optional`: Package will be removed from your `optionalDependencies`.
+
+Scope is optional and follows the usual rules for `npm-scope(7)`.
+
+Examples:
+
+    npm uninstall sax --save
+    npm uninstall @myorg/privatepackage --save
+    npm uninstall node-tap --save-dev
+    npm uninstall dtrace-provider --save-optional
+
+## SEE ALSO
+
+* npm-prune(1)
+* npm-install(1)
+* npm-folders(5)
+* npm-config(1)
+* npm-config(7)
+* npmrc(5)

node_modules/npm/doc/cli/npm-unpublish.md

@@ -0,0 +1,38 @@
+npm-unpublish(1) -- Remove a package from the registry
+======================================================
+
+## SYNOPSIS
+
+    npm unpublish [@<scope>/]<name>[@<version>]
+
+## WARNING
+
+**It is generally considered bad behavior to remove versions of a library
+that others are depending on!**
+
+Consider using the `deprecate` command
+instead, if your intent is to encourage users to upgrade.
+
+There is plenty of room on the registry.
+
+## DESCRIPTION
+
+This removes a package version from the registry, deleting its
+entry and removing the tarball.
+
+If no version is specified, or if all versions are removed then
+the root package entry is removed from the registry entirely.
+
+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.
+
+The scope is optional and follows the usual rules for `npm-scope(7)`.
+
+## SEE ALSO
+
+* npm-deprecate(1)
+* npm-publish(1)
+* npm-registry(7)
+* npm-adduser(1)
+* npm-owner(1)

node_modules/npm/doc/cli/npm-update.md

@@ -0,0 +1,148 @@
+npm-update(1) -- Update a package
+=================================
+
+## SYNOPSIS
+
+    npm update [-g] [<name> [<name> ...]]
+
+    aliases: up, upgrade
+
+## DESCRIPTION
+
+This command will update all the packages listed to the latest version
+(specified by the `tag` config), respecting semver.
+
+It will also install missing packages. As with all commands that install
+packages, the `--dev` flag will cause `devDependencies` to be processed
+as well.
+
+If the `-g` flag is specified, this command will update globally installed
+packages.
+
+If no package name is specified, all packages in the specified location (global
+or local) will be updated.
+
+As of `npm@2.6.1`, the `npm update` will only inspect top-level packages.
+Prior versions of `npm` would also recursively inspect all dependencies.
+To get the old behavior, use `npm --depth 9999 update`.
+
+## EXAMPLES
+
+IMPORTANT VERSION NOTE: these examples assume `npm@2.6.1` or later.  For
+older versions of `npm`, you must specify `--depth 0` to get the behavior
+described below.
+
+For the examples below, assume that the current package is `app` and it depends
+on dependencies, `dep1` (`dep2`, .. etc.).  The published versions of `dep1` are:
+
+```
+{
+  "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"
+  ]
+}
+```
+
+### Caret Dependencies
+
+If `app`'s `package.json` contains:
+
+```
+"dependencies": {
+  "dep1": "^1.1.1"
+}
+```
+
+Then `npm update` will install `dep1@1.2.2`, because `1.2.2` is `latest` and
+`1.2.2` satisfies `^1.1.1`.
+
+### Tilde Dependencies
+
+However, if `app`'s `package.json` contains:
+
+```
+"dependencies": {
+  "dep1": "~1.1.1"
+}
+```
+
+In this case, running `npm update` will install `dep1@1.1.2`.  Even though the `latest`
+tag points to `1.2.2`, this version does not satisfy `~1.1.1`, which is equivalent
+to `>=1.1.1 <1.2.0`.  So the highest-sorting version that satisfies `~1.1.1` is used,
+which is `1.1.2`.
+
+### Caret Dependencies below 1.0.0
+
+Suppose `app` has a caret dependency on a version below `1.0.0`, for example:
+
+```
+"dependencies": {
+  "dep1": "^0.2.0"
+}
+```
+
+`npm update` will install `dep1@0.2.0`, because there are no other
+versions which satisfy `^0.2.0`.
+
+If the dependence were on `^0.4.0`:
+
+```
+"dependencies": {
+  "dep1": "^0.4.0"
+}
+```
+
+Then `npm update` will install `dep1@0.4.1`, because that is the highest-sorting
+version that satisfies `^0.4.0` (`>= 0.4.0 <0.5.0`)
+
+### Recording Updates with `--save`
+
+When you want to update a package and save the new version as
+the minimum required dependency in `package.json`, you can use
+`npm update --save`.  For example if `package.json` contains
+
+```
+"dependencies": {
+  "dep1": "^1.1.1"
+}
+```
+
+Then `npm update --save` will install `dep1@1.2.2` (i.e., `latest`),
+and `package.json` will be modified:
+
+```
+"dependencies": {
+  "dep1": "^1.2.2"
+}
+```
+
+Note that `npm` will only write an updated version to `package.json`
+if it installs a new package.
+
+### Updating Globally-Installed Packages
+
+`npm update -g` will apply the `update` action to each globally installed
+package that is `outdated` -- that is, has a version that is different from
+`latest`.
+
+NOTE: If a package has been upgraded to a version newer than `latest`, it will
+be _downgraded_.
+
+
+## SEE ALSO
+
+* npm-install(1)
+* npm-outdated(1)
+* npm-shrinkwrap(1)
+* npm-registry(7)
+* npm-folders(5)
+* npm-ls(1)

node_modules/npm/doc/cli/npm-version.md

@@ -0,0 +1,90 @@
+npm-version(1) -- Bump a package version
+========================================
+
+## SYNOPSIS
+
+    npm version [<newversion> | major | minor | patch | premajor | preminor | prepatch | prerelease]
+
+## DESCRIPTION
+
+Run this in a package directory to bump the version and write the new
+data back to `package.json` and, if present, `npm-shrinkwrap.json`.
+
+The `newversion` argument should be a valid semver string, *or* a
+valid second argument to semver.inc (one of `patch`, `minor`, `major`,
+`prepatch`, `preminor`, `premajor`, `prerelease`). In the second case,
+the existing version will be incremented by 1 in the specified field.
+
+If run in a git repo, it will also create a version commit and tag.
+This behavior is controlled by `git-tag-version` (see below), and can 
+be disabled on the command line by running `npm --no-git-tag-version version`.
+It will fail if the working directory is not clean, unless the `--force`
+flag is set.
+
+If supplied with `--message` (shorthand: `-m`) config option, npm will
+use it as a commit message when creating a version commit.  If the
+`message` config contains `%s` then that will be replaced with the
+resulting version number.  For example:
+
+    npm version patch -m "Upgrade to %s for reasons"
+
+If the `sign-git-tag` config is set, then the tag will be signed using
+the `-s` 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:
+
+    $ 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:
+
+If `preversion`, `version`, or `postversion` are in the `scripts` property of
+the package.json, they will be executed as part of running `npm version`.
+
+The exact order of execution is as follows:
+  1. 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 `--force` flag is set.
+  2. Run the `preversion` script. These scripts have access to the old `version` 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 `git add`.
+  3. Bump `version` in `package.json` as requested (`patch`, `minor`, `major`, etc). 
+  4. Run the `version` script. These scripts have access to the new `version` 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 `git add`.
+  5. Commit and tag.
+  6. Run the `postversion` script. Use it to clean up the file system or automatically push 
+     the commit and/or tag.
+
+Take the following example:
+
+    "scripts": {
+      "preversion": "npm test",
+      "version": "npm run build && git add -A dist",
+      "postversion": "git push && git push --tags && rm -rf build/temp"
+    }
+
+This runs all your tests, and proceeds only if they pass. Then runs your `build` script, and
+adds everything in the `dist` directory to the commit. After the commit, it pushes the new commit
+and tag up to the server, and deletes the `build/temp` directory.
+
+## CONFIGURATION
+
+### git-tag-version
+
+* Default: true
+* Type: Boolean
+
+Commit and tag the version change.
+
+## SEE ALSO
+
+* npm-init(1)
+* npm-run-script(1)
+* npm-scripts(7)
+* package.json(5)
+* semver(7)
+* config(7)

node_modules/npm/doc/cli/npm-view.md

@@ -0,0 +1,95 @@
+npm-view(1) -- View registry info
+=================================
+
+## SYNOPSIS
+
+    npm view [@<scope>/]<name>[@<version>] [<field>[.<subfield>]...]
+    npm v [@<scope>/]<name>[@<version>] [<field>[.<subfield>]...]
+
+## DESCRIPTION
+
+This command shows data about a package and prints it to the stream
+referenced by the `outfd` config, which defaults to stdout.
+
+To show the package registry entry for the `connect` package, you can do
+this:
+
+    npm view connect
+
+The default version is "latest" if unspecified.
+
+Field names can be specified after the package descriptor.
+For example, to show the dependencies of the `ronn` package at version
+0.3.5, you could do the following:
+
+    npm view ronn@0.3.5 dependencies
+
+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:
+
+    npm view npm repository.url
+
+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:
+
+    npm view opts@$(npm view ronn dependencies.opts)
+
+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:
+
+    npm view express contributors.email
+
+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:
+
+    npm view express contributors[0].email
+
+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:
+
+    npm view express contributors.name contributors.email
+
+"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 `package.json(5)` for more on this.)
+
+    npm view npm contributors
+
+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:
+
+    npm view yui3@'>0.5.4' dependencies.jsdom
+
+To show the `connect` package version history, you can do
+this:
+
+    npm view connect versions
+
+## OUTPUT
+
+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.
+
+If the --json flag is given, the outputted fields will be JSON.
+
+If the version range matches multiple versions, than each printed value
+will be prefixed with the version it applies to.
+
+If multiple fields are requested, than each of them are prefixed with
+the field name.
+
+## SEE ALSO
+
+* npm-search(1)
+* npm-registry(7)
+* npm-config(1)
+* npm-config(7)
+* npmrc(5)
+* npm-docs(1)

node_modules/npm/doc/cli/npm-whoami.md

@@ -0,0 +1,17 @@
+npm-whoami(1) -- Display npm username
+=====================================
+
+## SYNOPSIS
+
+    npm whoami
+
+## DESCRIPTION
+
+Print the `username` config to standard output.
+
+## SEE ALSO
+
+* npm-config(1)
+* npm-config(7)
+* npmrc(5)
+* npm-adduser(1)

node_modules/npm/doc/cli/npm.md

@@ -0,0 +1,167 @@
+npm(1) -- javascript package manager
+====================================
+
+## SYNOPSIS
+
+    npm <command> [args]
+
+## VERSION
+
+@VERSION@
+
+## DESCRIPTION
+
+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.
+
+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.
+
+Run `npm help` to get a list of available commands.
+
+## INTRODUCTION
+
+You probably got npm because you want to install stuff.
+
+Use `npm install blerg` to install the latest version of "blerg".  Check out
+`npm-install(1)` for more info.  It can do a lot of stuff.
+
+Use the `npm search` command to show everything that's available.
+Use `npm ls` to show everything you've installed.
+
+## DEPENDENCIES
+
+If a package references to another package with a git URL, npm depends
+on a preinstalled git.
+
+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](https://github.com/TooTallNate/node-gyp) for that task.
+For a Unix system, [node-gyp](https://github.com/TooTallNate/node-gyp)
+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](https://github.com/TooTallNate/node-gyp).
+For more information visit
+[the node-gyp repository](https://github.com/TooTallNate/node-gyp) and
+the [node-gyp Wiki](https://github.com/TooTallNate/node-gyp/wiki).
+
+## DIRECTORIES
+
+See `npm-folders(5)` to learn about where npm puts stuff.
+
+In particular, npm has two modes of operation:
+
+* global mode:  
+  npm installs packages into the install prefix at
+  `prefix/lib/node_modules` and bins are installed in `prefix/bin`.
+* local mode:  
+  npm installs packages into the current project directory, which
+  defaults to the current working directory.  Packages are installed to
+  `./node_modules`, and bins are installed to `./node_modules/.bin`.
+
+Local mode is the default.  Use `--global` or `-g` on any command to
+operate in global mode instead.
+
+## DEVELOPER USAGE
+
+If you're using npm to develop and publish your code, check out the
+following help topics:
+
+* json:
+  Make a package.json file.  See `package.json(5)`.
+* 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
+  `npm link` to do this.
+* 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
+  `npm install`
+* adduser:
+  Create an account or log in.  Credentials are stored in the
+  user config file.
+* publish:
+  Use the `npm publish` command to upload your code to the registry.
+
+## CONFIGURATION
+
+npm is extremely configurable.  It reads its configuration options from
+5 places.
+
+* Command line switches:  
+  Set a config with `--key val`.  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 `true`.
+* Environment Variables:  
+  Set any config by prefixing the name in an environment variable with
+  `npm_config_`.  For example, `export npm_config_key=val`.
+* User Configs:  
+  The file at $HOME/.npmrc is an ini-formatted list of configs.  If
+  present, it is parsed.  If the `userconfig` option is set in the cli
+  or env, then that will be used instead.
+* Global Configs:  
+  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 `globalconfig` option is set in the cli, env, or user config,
+  then that file is parsed instead.
+* Defaults:  
+  npm's default configuration options are defined in
+  lib/utils/config-defs.js.  These must not be changed.
+
+See `npm-config(7)` for much much more information.
+
+## CONTRIBUTIONS
+
+Patches welcome!
+
+* code:
+  Read through `npm-coding-style(7)` if you plan to submit code.
+  You don't have to agree with it, but you do have to follow it.
+* 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.)
+
+Contributors are listed in npm's `package.json` file.  You can view them
+easily by doing `npm view npm contributors`.
+
+If you would like to contribute, but don't know what to work on, read
+the contributing guidelines and check the issues list.
+
+* https://github.com/npm/npm/wiki/Contributing-Guidelines
+* <https://github.com/npm/npm/issues>
+
+## BUGS
+
+When you find issues, please report them:
+
+* web:
+  <https://github.com/npm/npm/issues>
+
+Be sure to include *all* of the output from the npm command that didn't work
+as expected.  The `npm-debug.log` file is also helpful to provide.
+
+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.
+
+## AUTHOR
+
+[Isaac Z. Schlueter](http://blog.izs.me/) ::
+[isaacs](https://github.com/isaacs/) ::
+[@izs](http://twitter.com/izs) ::
+<i@izs.me>
+
+## SEE ALSO
+
+* npm-help(1)
+* npm-faq(7)
+* README
+* package.json(5)
+* npm-install(1)
+* npm-config(1)
+* npm-config(7)
+* npmrc(5)
+* npm-index(7)
+* npm(3)

node_modules/npm/doc/files/npm-folders.md

@@ -0,0 +1,215 @@
+npm-folders(5) -- Folder Structures Used by npm
+===============================================
+
+## DESCRIPTION
+
+npm puts various things on your computer.  That's its job.
+
+This document will tell you what it puts where.
+
+### tl;dr
+
+* Local install (default): puts stuff in `./node_modules` of the current
+  package root.
+* Global install (with `-g`): puts stuff in /usr/local or wherever node
+  is installed.
+* Install it **locally** if you're going to `require()` it.
+* Install it **globally** if you're going to run it on the command line.
+* If you need both, then install it in both places, or use `npm link`.
+
+### prefix Configuration
+
+The `prefix` config defaults to the location where node is installed.
+On most systems, this is `/usr/local`. 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 `{prefix}/bin/node` rather than 
+`{prefix}/node.exe`.
+
+When the `global` 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.
+
+### Node Modules
+
+Packages are dropped into the `node_modules` folder under the `prefix`.
+When installing locally, this means that you can
+`require("packagename")` to load its main module, or
+`require("packagename/lib/path/to/sub/module")` to load other modules.
+
+Global installs on Unix systems go to `{prefix}/lib/node_modules`.
+Global installs on Windows go to `{prefix}/node_modules` (that is, no
+`lib` folder.)
+
+Scoped packages are installed the same way, except they are grouped together
+in a sub-folder of the relevant `node_modules` folder with the name of that
+scope prefix by the @ symbol, e.g. `npm install @myorg/package` would place
+the package in `{prefix}/node_modules/@myorg/package`. See `scope(7)` for
+more details.
+
+If you wish to `require()` a package, then install it locally.
+
+### Executables
+
+When in global mode, executables are linked into `{prefix}/bin` on Unix,
+or directly into `{prefix}` on Windows.
+
+When in local mode, executables are linked into
+`./node_modules/.bin` 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 `npm test`.)
+
+### Man Pages
+
+When in global mode, man pages are linked into `{prefix}/share/man`.
+
+When in local mode, man pages are not installed.
+
+Man pages are not installed on Windows systems.
+
+### Cache
+
+See `npm-cache(1)`.  Cache files are stored in `~/.npm` on Posix, or
+`~/npm-cache` on Windows.
+
+This is controlled by the `cache` configuration param.
+
+### Temp Files
+
+Temporary files are stored by default in the folder specified by the
+`tmp` config, which defaults to the TMPDIR, TMP, or TEMP environment
+variables, or `/tmp` on Unix and `c:\windows\temp` on Windows.
+
+Temp files are given a unique folder under this root for each run of the
+program, and are deleted upon successful exit.
+
+## More Information
+
+When installing locally, npm first tries to find an appropriate
+`prefix` folder.  This is so that `npm install foo@1.2.3` will install
+to the sensible root of your package, even if you happen to have `cd`ed
+into some other folder.
+
+Starting at the $PWD, npm will walk up the folder tree checking for a
+folder that contains either a `package.json` file, or a `node_modules`
+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.)
+
+If no package root is found, then the current folder is used.
+
+When you run `npm install foo@1.2.3`, then the package is loaded into
+the cache, and then unpacked into `./node_modules/foo`.  Then, any of
+foo's dependencies are similarly unpacked into
+`./node_modules/foo/node_modules/...`.
+
+Any bin files are symlinked to `./node_modules/.bin/`, so that they may
+be found by npm scripts when necessary.
+
+### Global Installation
+
+If the `global` configuration is set to true, then npm will
+install packages "globally".
+
+For global installation, packages are installed roughly the same way,
+but using the folders described above.
+
+### Cycles, Conflicts, and Folder Parsimony
+
+Cycles are handled using the property of node's module system that it
+walks up the directories looking for `node_modules` folders.  So, at every
+stage, if a package is already installed in an ancestor `node_modules`
+folder, then it is not installed at the current location.
+
+Consider the case above, where `foo -> bar -> baz`.  Imagine if, in
+addition to that, baz depended on bar, so you'd have:
+`foo -> bar -> baz -> bar -> baz ...`.  However, since the folder
+structure is: `foo/node_modules/bar/node_modules/baz`, there's no need to
+put another copy of bar into `.../baz/node_modules`, since when it calls
+require("bar"), it will get the copy that is installed in
+`foo/node_modules/bar`.
+
+This shortcut is only used if the exact same
+version would be installed in multiple nested `node_modules` folders.  It
+is still possible to have `a/node_modules/b/node_modules/a` if the two
+"a" packages are different versions.  However, without repeating the
+exact same package multiple times, an infinite regress will always be
+prevented.
+
+Another optimization can be made by installing dependencies at the
+highest level possible, below the localized "target" folder.
+
+#### Example
+
+Consider this dependency graph:
+
+    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
+
+In this case, we might expect a folder structure like this:
+
+    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]
+
+Since foo depends directly on `bar@1.2.3` and `baz@1.2.3`, those are
+installed in foo's `node_modules` folder.
+
+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 `blerg@1.x`,
+it does not install another copy under [B].
+
+Bar [B] also has dependencies on baz and asdf, so those are installed in
+bar's `node_modules` folder.  Because it depends on `baz@2.x`, it cannot
+re-use the `baz@1.2.3` installed in the parent `node_modules` folder [D],
+and must install its own copy [C].
+
+Underneath bar, the `baz -> quux -> bar` 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.
+
+Underneath `foo -> baz` [D], quux's [E] folder tree is empty, because its
+dependency on bar is satisfied by the parent folder copy installed at [B].
+
+For a graphical breakdown of what is installed where, use `npm ls`.
+
+### Publishing
+
+Upon publishing, npm will look in the `node_modules` folder.  If any of
+the items there are not in the `bundledDependencies` array, then they will
+not be included in the package tarball.
+
+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 `package.json(5)` for more information.
+
+## SEE ALSO
+
+* npm-faq(7)
+* package.json(5)
+* npm-install(1)
+* npm-pack(1)
+* npm-cache(1)
+* npm-config(1)
+* npmrc(5)
+* npm-config(7)
+* npm-publish(1)

node_modules/npm/doc/files/npmrc.md

@@ -0,0 +1,95 @@
+npmrc(5) -- The npm config files
+================================
+
+## DESCRIPTION
+
+npm gets its config settings from the command line, environment
+variables, and `npmrc` files.
+
+The `npm config` command can be used to update and edit the contents
+of the user and global npmrc files.
+
+For a list of available configuration options, see npm-config(7).
+
+## FILES
+
+The four relevant files are:
+
+* per-project config file (/path/to/my/project/.npmrc)
+* per-user config file (~/.npmrc)
+* global config file ($PREFIX/etc/npmrc)
+* npm builtin config file (/path/to/npm/npmrc)
+
+All npm config files are an ini-formatted list of `key = value`
+parameters.  Environment variables can be replaced using
+`${VARIABLE_NAME}`. For example:
+
+    prefix = ${HOME}/.npm-packages
+
+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.
+
+Array values are specified by adding "[]" after the key name. For
+example:
+
+    key[] = "first value"
+    key[] = "second value"
+
+**NOTE:** Because local (per-project or per-user) `.npmrc` files can contain
+sensitive credentials, they must be readable and writable _only_ by your user
+account (i.e. must have a mode of `0600`), otherwise they _will be ignored by
+npm!_
+
+#### Comments
+
+Lines in `.npmrc` files are interpreted as comments when they begin with a `;` or `#` character. `.npmrc` files are parsed by [npm/ini](https://github.com/npm/ini), which specifies this comment syntax.
+
+For example:
+
+    # last modified: 01 Jan 2016
+    ; Set a new registry for a scoped package
+    @myscope:registry=https://mycustomregistry.example.org
+
+### Per-project config file
+
+When working locally in a project, a `.npmrc` file in the root of the
+project (ie, a sibling of `node_modules` and `package.json`) will set
+config values specific to this project.
+
+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.
+
+Additionally, this file is not read in global mode, such as when running
+`npm install -g`.
+
+### Per-user config file
+
+`$HOME/.npmrc` (or the `userconfig` param, if set in the environment
+or on the command line)
+
+### Global config file
+
+`$PREFIX/etc/npmrc` (or the `globalconfig` param, if set above):
+This file is an ini-file formatted list of `key = value` parameters.
+Environment variables can be replaced as above.
+
+### Built-in config file
+
+`path/to/npm/itself/npmrc`
+
+This is an unchangeable "builtin" configuration file that npm keeps
+consistent across updates.  Set fields in here using the `./configure`
+script that comes with npm.  This is primarily for distribution
+maintainers to override default configs in a standard and consistent
+manner.
+
+## SEE ALSO
+
+* npm-folders(5)
+* npm-config(1)
+* npm-config(7)
+* package.json(5)
+* npm(1)

node_modules/npm/doc/files/package.json.md

@@ -0,0 +1,764 @@
+package.json(5) -- Specifics of npm's package.json handling
+===========================================================
+
+## DESCRIPTION
+
+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.
+
+A lot of the behavior described in this document is affected by the config
+settings described in `npm-config(7)`.
+
+## name
+
+The *most* 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.
+
+The name is what your thing is called.
+
+Some rules:
+
+* The name must be less than or equal to 214 characters. This includes the scope for
+  scoped packages.
+* The name can't start with a dot or an underscore.
+* New packages must not have uppercase letters in the name.
+* 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.
+
+Some tips:
+
+* Don't use the same name as a core Node module.
+* 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.)
+* The name will probably be passed as an argument to require(), so it should
+  be something short, but also reasonably descriptive.
+* 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/>
+
+A name can be optionally prefixed by a scope, e.g. `@myorg/mypackage`. See
+`npm-scope(7)` for more detail.
+
+## version
+
+The *most* 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.
+
+Version must be parseable by
+[node-semver](https://github.com/isaacs/node-semver), which is bundled
+with npm as a dependency.  (`npm install semver` to use it yourself.)
+
+More on version numbers and ranges at semver(7).
+
+## description
+
+Put a description in it.  It's a string.  This helps people discover your
+package, as it's listed in `npm search`.
+
+## keywords
+
+Put keywords in it.  It's an array of strings.  This helps people
+discover your package as it's listed in `npm search`.
+
+## homepage
+
+The url to the project homepage.
+
+**NOTE**: This is *not* 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.
+
+Literally.  Spit.  I'm so not kidding.
+
+## bugs
+
+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.
+
+It should look like this:
+
+    { "url" : "https://github.com/owner/project/issues"
+    , "email" : "project@hostname.com"
+    }
+
+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.
+
+If a url is provided, it will be used by the `npm bugs` command.
+
+## license
+
+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.
+
+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:
+
+    { "license" : "BSD-3-Clause" }
+
+You can check [the full list of SPDX license IDs](https://spdx.org/licenses/).
+Ideally you should pick one that is
+[OSI](https://opensource.org/licenses/alphabetical) approved.
+
+If your package is licensed under multiple common licenses, use an [SPDX license
+expression syntax version 2.0 string](https://npmjs.com/package/spdx), like this:
+
+    { "license" : "(ISC OR GPL-3.0)" }
+
+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:
+
+    { "license" : "SEE LICENSE IN <filename>" }
+
+Then include a file named `<filename>` at the top level of the package.
+
+Some old packages used license objects or a "licenses" property containing an
+array of license objects:
+
+    // 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"
+        }
+      ]
+    }
+
+Those styles are now deprecated. Instead, use SPDX expressions, like this:
+
+    { "license": "ISC" }
+
+    { "license": "(MIT OR Apache-2.0)" }
+
+Finally, if you do not wish to grant others the right to use a private or
+unpublished package under any terms:
+
+    { "license": "UNLICENSED"}
+
+Consider also setting `"private": true` to prevent accidental publication.
+
+## people fields: author, contributors
+
+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:
+
+    { "name" : "Barney Rubble"
+    , "email" : "b@rubble.com"
+    , "url" : "http://barnyrubble.tumblr.com/"
+    }
+
+Or you can shorten that all into a single string, and npm will parse it for you:
+
+    "Barney Rubble <b@rubble.com> (http://barnyrubble.tumblr.com/)"
+
+Both email and url are optional either way.
+
+npm also sets a top-level "maintainers" field with your npm user info.
+
+## files
+
+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.)
+
+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 `.npmignore` file
+works just like a `.gitignore`.
+
+Certain files are always included, regardless of settings:
+
+* `package.json`
+* `README`
+* `CHANGES` / `CHANGELOG` / `HISTORY` (any casing and file extension)
+* `LICENSE` / `LICENCE`
+* The file in the "main" field
+
+Conversely, some files are always ignored:
+
+* `.git`
+* `CVS`
+* `.svn`
+* `.hg`
+* `.lock-wscript`
+* `.wafpickle-N`
+* `.*.swp`
+* `.DS_Store`
+* `._*`
+* `npm-debug.log`
+* `.npmrc`
+* `node_modules`
+
+## main
+
+The main field is a module ID that is the primary entry point to your program.
+That is, if your package is named `foo`, and a user installs it, and then does
+`require("foo")`, then your main module's exports object will be returned.
+
+This should be a module ID relative to the root of your package folder.
+
+For most modules, it makes the most sense to have a main script and often not
+much else.
+
+## bin
+
+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.)
+
+To use this, supply a `bin` field in your package.json which is a map of
+command name to local file name. On install, npm will symlink that file into
+`prefix/bin` for global installs, or `./node_modules/.bin/` for local
+installs.
+
+
+For example, myapp could have this:
+
+    { "bin" : { "myapp" : "./cli.js" } }
+
+So, when you install myapp, it'll create a symlink from the `cli.js` script to
+`/usr/local/bin/myapp`.
+
+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:
+
+    { "name": "my-program"
+    , "version": "1.2.5"
+    , "bin": "./path/to/program" }
+
+would be the same as this:
+
+    { "name": "my-program"
+    , "version": "1.2.5"
+    , "bin" : { "my-program" : "./path/to/program" } }
+
+Please make sure that your file(s) referenced in `bin` starts with
+`#!/usr/bin/env node`, otherwise the scripts are started without the node
+executable!
+
+## man
+
+Specify either a single file or an array of filenames to put in place for the
+`man` program to find.
+
+If only a single file is provided, then it's installed such that it is the
+result from `man <pkgname>`, regardless of its actual filename.  For example:
+
+    { "name" : "foo"
+    , "version" : "1.2.3"
+    , "description" : "A packaged foo fooer for fooing foos"
+    , "main" : "foo.js"
+    , "man" : "./man/doc.1"
+    }
+
+would link the `./man/doc.1` file in such that it is the target for `man foo`
+
+If the filename doesn't start with the package name, then it's prefixed.
+So, this:
+
+    { "name" : "foo"
+    , "version" : "1.2.3"
+    , "description" : "A packaged foo fooer for fooing foos"
+    , "main" : "foo.js"
+    , "man" : [ "./man/foo.1", "./man/bar.1" ]
+    }
+
+will create files to do `man foo` and `man foo-bar`.
+
+Man files must end with a number, and optionally a `.gz` suffix if they are
+compressed.  The number dictates which man section the file is installed into.
+
+    { "name" : "foo"
+    , "version" : "1.2.3"
+    , "description" : "A packaged foo fooer for fooing foos"
+    , "main" : "foo.js"
+    , "man" : [ "./man/foo.1", "./man/foo.2" ]
+    }
+
+will create entries for `man foo` and `man 2 foo`
+
+## directories
+
+The CommonJS [Packages](http://wiki.commonjs.org/wiki/Packages/1.0) spec details a
+few ways that you can indicate the structure of your package using a `directories`
+object. If you look at [npm's package.json](https://registry.npmjs.org/npm/latest),
+you'll see that it has directories for doc, lib, and man.
+
+In the future, this information may be used in other creative ways.
+
+### directories.lib
+
+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.
+
+### directories.bin
+
+If you specify a `bin` directory in `directories.bin`, all the files in
+that folder will be added.
+
+Because of the way the `bin` directive works, specifying both a
+`bin` path and setting `directories.bin` is an error. If you want to
+specify individual files, use `bin`, and for all the files in an
+existing `bin` directory, use `directories.bin`.
+
+### directories.man
+
+A folder that is full of man pages.  Sugar to generate a "man" array by
+walking the folder.
+
+### directories.doc
+
+Put markdown files in here.  Eventually, these will be displayed nicely,
+maybe, someday.
+
+### directories.example
+
+Put example scripts in here.  Someday, it might be exposed in some clever way.
+
+### directories.test
+
+Put your tests in here. It is currently not exposed, but it might be in the
+future.
+
+## repository
+
+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 `npm docs`
+command will be able to find you.
+
+Do it like this:
+
+    "repository" :
+      { "type" : "git"
+      , "url" : "https://github.com/npm/npm.git"
+      }
+
+    "repository" :
+      { "type" : "svn"
+      , "url" : "https://v8.googlecode.com/svn/trunk/"
+      }
+
+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.
+
+For GitHub, GitHub gist, Bitbucket, or GitLab repositories you can use the same
+shortcut syntax you use for `npm install`:
+
+    "repository": "npm/npm"
+
+    "repository": "gist:11081aaa281"
+
+    "repository": "bitbucket:example/repo"
+
+    "repository": "gitlab:another/repo"
+
+## scripts
+
+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.
+
+See `npm-scripts(7)` to find out more about writing package scripts.
+
+## config
+
+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:
+
+    { "name" : "foo"
+    , "config" : { "port" : "8080" } }
+
+and then had a "start" command that then referenced the
+`npm_package_config_port` environment variable, then the user could
+override that by doing `npm config set foo:port 8001`.
+
+See `npm-config(7)` and `npm-scripts(7)` for more on package
+configs.
+
+## dependencies
+
+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.
+
+**Please do not put test harnesses or transpilers in your
+`dependencies` object.**  See `devDependencies`, below.
+
+See semver(7) for more details about specifying version ranges.
+
+* `version` Must match `version` exactly
+* `>version` Must be greater than `version`
+* `>=version` etc
+* `<version`
+* `<=version`
+* `~version` "Approximately equivalent to version"  See semver(7)
+* `^version` "Compatible with version"  See semver(7)
+* `1.2.x` 1.2.0, 1.2.1, etc., but not 1.3.0
+* `http://...` See 'URLs as Dependencies' below
+* `*` Matches any version
+* `""` (just an empty string) Same as `*`
+* `version1 - version2` Same as `>=version1 <=version2`.
+* `range1 || range2` Passes if either range1 or range2 are satisfied.
+* `git...` See 'Git URLs as Dependencies' below
+* `user/repo` See 'GitHub URLs' below
+* `tag` A specific version tagged and published as `tag`  See `npm-tag(1)`
+* `path/path/path` See [Local Paths](#local-paths) below
+
+For example, these are all valid:
+
+    { "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"
+      }
+    }
+
+### URLs as Dependencies
+
+You may specify a tarball URL in place of a version range.
+
+This tarball will be downloaded and installed locally to your package at
+install time.
+
+### Git URLs as Dependencies
+
+Git urls can be of the form:
+
+    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
+
+The `commit-ish` can be any tag, sha, or branch which can be supplied as
+an argument to `git checkout`.  The default is `master`.
+
+## GitHub URLs
+
+As of version 1.1.65, you can refer to GitHub urls as just "foo":
+"user/foo-project".  Just as with git URLs, a `commit-ish` suffix can be
+included.  For example:
+
+    {
+      "name": "foo",
+      "version": "0.0.0",
+      "dependencies": {
+        "express": "visionmedia/express",
+        "mocha": "visionmedia/mocha#4727d357ea"
+      }
+    }
+
+## Local Paths
+
+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 `npm install --save`, using any of
+these forms:
+
+    ../foo/bar
+    ~/foo/bar
+    ./foo/bar
+    /foo/bar
+
+in which case they will be normalized to a relative path and added to your
+`package.json`. For example:
+
+    {
+      "name": "baz",
+      "dependencies": {
+        "bar": "file:../foo/bar"
+      }
+    }
+
+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.
+
+## devDependencies
+
+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.
+
+In this case, it's best to map these additional items in a `devDependencies`
+object.
+
+These things will be installed when doing `npm link` or `npm install`
+from the root of a package, and can be managed like any other npm
+configuration param.  See `npm-config(7)` for more on the topic.
+
+For build steps that are not platform-specific, such as compiling
+CoffeeScript or other languages to JavaScript, use the `prepublish`
+script to do this, and make the required package a devDependency.
+
+For example:
+
+    { "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"
+    }
+
+The `prepublish` 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 `npm install`), it'll
+run this script as well, so that you can test it easily.
+
+## peerDependencies
+
+In some cases, you want to express the compatibility of your package with a
+host tool or library, while not necessarily doing a `require` of this host.
+This is usually referred to as a *plugin*. Notably, your module may be exposing
+a specific interface, expected and specified by the host documentation.
+
+For example:
+
+    {
+      "name": "tea-latte",
+      "version": "1.3.5",
+      "peerDependencies": {
+        "tea": "2.x"
+      }
+    }
+
+This ensures your package `tea-latte` can be installed *along* with the second
+major version of the host package `tea` only. `npm install tea-latte` could
+possibly yield the following dependency graph:
+
+    ├── tea-latte@1.3.5
+    └── tea@2.2.0
+
+**NOTE: npm versions 1 and 2 will automatically install `peerDependencies` 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.** 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.
+
+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.
+
+Assuming the host complies with [semver](http://semver.org/), 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 `"^1.0"` or `"1.x"` to express
+this. If you depend on features introduced in 1.5.2, use `">= 1.5.2 < 2"`.
+
+## bundledDependencies
+
+This defines an array of package names that will be bundled when publishing the package.
+
+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 `bundledDependencies` array and executing `npm pack`.
+
+For example:
+If we define a package.json like this:
+
+```
+{
+  "name": "awesome-web-framework",
+  "version": "1.0.0",
+  "bundledDependencies": [
+    'renderized', 'super-streams'
+  ]
+}
+```
+we can obtain `awesome-web-framework-1.0.0.tgz` file by running `npm pack`. This file contains the dependencies `renderized` and `super-streams` which can be installed in a new project by executing `npm install awesome-web-framework-1.0.0.tgz`.
+
+If this is spelled `"bundleDependencies"`, then that is also honored.
+
+## optionalDependencies
+
+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 `optionalDependencies`
+object.  This is a map of package name to version or url, just like the
+`dependencies` object.  The difference is that build failures do not cause
+installation to fail.
+
+It is still your program's responsibility to handle the lack of the
+dependency.  For example, something like this:
+
+    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()
+    }
+
+Entries in `optionalDependencies` will override entries of the same name in
+`dependencies`, so it's usually best to only put in one place.
+
+## engines
+
+You can specify the version of node that your stuff works on:
+
+    { "engines" : { "node" : ">=0.10.3 <0.12" } }
+
+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.
+
+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.
+
+You can also use the "engines" field to specify which versions of npm
+are capable of properly installing your program.  For example:
+
+    { "engines" : { "npm" : "~1.0.20" } }
+
+Unless the user has set the `engine-strict` config flag, this
+field is advisory only will produce warnings when your package is installed as a dependency.
+
+## engineStrict
+
+**NOTE: This feature is deprecated and will be removed in npm 3.0.0.**
+
+If you are sure that your module will *definitely not* run properly on
+versions of Node/npm other than those specified in the `engines` object,
+then you can set `"engineStrict": true` in your package.json file.
+This will override the user's `engine-strict` config setting.
+
+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.
+
+## os
+
+You can specify which operating systems your
+module will run on:
+
+    "os" : [ "darwin", "linux" ]
+
+You can also blacklist instead of whitelist operating systems,
+just prepend the blacklisted os with a '!':
+
+    "os" : [ "!win32" ]
+
+The host operating system is determined by `process.platform`
+
+It is allowed to both blacklist, and whitelist, although there isn't any
+good reason to do this.
+
+## cpu
+
+If your code only runs on certain cpu architectures,
+you can specify which ones.
+
+    "cpu" : [ "x64", "ia32" ]
+
+Like the `os` option, you can also blacklist architectures:
+
+    "cpu" : [ "!arm", "!mips" ]
+
+The host architecture is determined by `process.arch`
+
+## preferGlobal
+
+If your package is primarily a command-line application that should be
+installed globally, then set this value to `true` to provide a warning
+if it is installed locally.
+
+It doesn't actually prevent users from installing it locally, but it
+does help prevent some confusion if it doesn't work as expected.
+
+## private
+
+If you set `"private": true` in your package.json, then npm will refuse
+to publish it.
+
+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
+`publishConfig` dictionary described below to override the `registry` config
+param at publish-time.
+
+## publishConfig
+
+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.
+
+Any config values can be overridden, but of course only "tag", "registry" and
+"access" probably matter for the purposes of publishing.
+
+See `npm-config(7)` to see the list of config options that can be
+overridden.
+
+## DEFAULT VALUES
+
+npm will default some values based on package contents.
+
+* `"scripts": {"start": "node server.js"}`
+
+  If there is a `server.js` file in the root of your package, then npm
+  will default the `start` command to `node server.js`.
+
+* `"scripts":{"install": "node-gyp rebuild"}`
+
+  If there is a `binding.gyp` file in the root of your package and you have not defined an `install` or `preinstall` script, npm will
+  default the `install` command to compile using node-gyp.
+
+* `"contributors": [...]`
+
+  If there is an `AUTHORS` file in the root of your package, npm will
+  treat each line as a `Name <email> (url)` format, where email and url
+  are optional.  Lines which start with a `#` or are blank, will be
+  ignored.
+
+## SEE ALSO
+
+* semver(7)
+* npm-init(1)
+* npm-version(1)
+* npm-config(1)
+* npm-config(7)
+* npm-help(1)
+* npm-faq(7)
+* npm-install(1)
+* npm-publish(1)
+* npm-uninstall(1)

node_modules/npm/doc/misc/npm-coding-style.md

@@ -0,0 +1,181 @@
+npm-coding-style(7) -- npm's "funny" coding style
+=================================================
+
+## DESCRIPTION
+
+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.
+
+If you want to contribute to npm (which is very encouraged), you should
+make your code conform to npm's style.
+
+Note: this concerns npm's code not the specific packages that you can download from the npm registry.
+
+## Line Length
+
+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.
+
+## Indentation
+
+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.
+
+Configure your editor appropriately.
+
+## Curly braces
+
+Curly braces belong on the same line as the thing that necessitates them.
+
+Bad:
+
+    function ()
+    {
+
+Good:
+
+    function () {
+
+If a block needs to wrap to the next line, use a curly brace.  Don't
+use it if it doesn't.
+
+Bad:
+
+    if (foo) { bar() }
+    while (foo)
+      bar()
+
+Good:
+
+    if (foo) bar()
+    while (foo) {
+      bar()
+    }
+
+## Semicolons
+
+Don't use them except in four situations:
+
+* `for (;;)` loops.  They're actually required.
+* null loops like: `while (something) ;` (But you'd better have a good
+  reason for doing that.)
+* `case "foo": doSomething(); break`
+* In front of a leading `(` or `[` at the start of the line.
+  This prevents the expression from being interpreted
+  as a function call or property access, respectively.
+
+Some examples of good semicolon usage:
+
+    ;(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()
+    }
+
+Note that starting lines with `-` and `+` also should be prefixed
+with a semicolon, but this is much less common.
+
+## Comma First
+
+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:
+
+    var magicWords = [ "abracadabra"
+                     , "gesundheit"
+                     , "ventrilo"
+                     ]
+      , spells = { "fireball" : function () { setOnFire() }
+                 , "water" : function () { putOut() }
+                 }
+      , a = 1
+      , b = "abc"
+      , etc
+      , somethingElse
+
+## Whitespace
+
+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.
+
+Don't leave trailing whitespace at the end of lines.  Don't indent empty
+lines.  Don't use more spaces than are helpful.
+
+## Functions
+
+Use named functions.  They make stack traces a lot easier to read.
+
+## Callbacks, Sync/async Style
+
+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.
+
+The callback should always be the last argument in the list.  Its first
+argument is the Error or null.
+
+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.
+
+## Errors
+
+Always create a new Error object with your message.  Don't just return a
+string message to the callback.  Stack traces are handy.
+
+## Logging
+
+Logging is done using the [npmlog](https://github.com/npm/npmlog)
+utility.
+
+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.
+
+Use appropriate log levels.  See `npm-config(7)` and search for
+"loglevel".
+
+## Case, naming, etc.
+
+Use `lowerCamelCase` for multiword identifiers when they refer to objects,
+functions, methods, properties, or anything not specified in this section.
+
+Use `UpperCamelCase` for class names (things that you'd pass to "new").
+
+Use `all-lower-hyphen-css-case` for multiword filenames and config keys.
+
+Use named functions.  They make stack traces easier to follow.
+
+Use `CAPS_SNAKE_CASE` for constants, things that should never change
+and are rarely used.
+
+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.
+
+## null, undefined, false, 0
+
+Boolean variables and functions should always be either `true` or
+`false`.  Don't set it to 0 unless it's supposed to be a number.
+
+When something is intentionally missing or removed, set it to `null`.
+
+Don't set things to `undefined`.  Reserve that value to mean "not yet
+set to anything."
+
+Boolean objects are verboten.
+
+## SEE ALSO
+
+* npm-developers(7)
+* npm-faq(7)
+* npm(1)

node_modules/npm/doc/misc/npm-config.md

@@ -0,0 +1,940 @@
+npm-config(7) -- More than you probably want to know about npm configuration
+============================================================================
+
+## DESCRIPTION
+
+npm gets its configuration values from the following sources, sorted by priority:
+
+### Command Line Flags
+
+Putting `--foo bar` on the command line sets the `foo` configuration
+parameter to `"bar"`.  A `--` argument tells the cli parser to stop
+reading flags.  A `--flag` parameter that is at the *end* of the
+command will be given the value of `true`.
+
+### Environment Variables
+
+Any environment variables that start with `npm_config_` will be
+interpreted as a configuration parameter.  For example, putting
+`npm_config_foo=bar` in your environment will set the `foo`
+configuration parameter to `bar`.  Any environment configurations that
+are not given a value will be given the value of `true`.  Config
+values are case-insensitive, so `NPM_CONFIG_FOO=bar` will work the
+same.
+
+### npmrc Files
+
+The four relevant files are:
+
+* per-project configuration file (`/path/to/my/project/.npmrc`)
+* per-user configuration file (defaults to `$HOME/.npmrc`; configurable via CLI
+  option `--userconfig` or environment variable `$NPM_CONF_USERCONFIG`)
+* global configuration file (defaults to `$PREFIX/etc/npmrc`; configurable via
+  CLI option `--globalconfig` or environment variable `$NPM_CONF_GLOBALCONFIG`)
+* npm's built-in configuration file (`/path/to/npm/npmrc`)
+
+See npmrc(5) for more details.
+
+### Default Configs
+
+A set of configuration parameters that are internal to npm, and are
+defaults if nothing else is specified.
+
+## Shorthands and Other CLI Niceties
+
+The following shorthands are parsed on the command-line:
+
+* `-v`: `--version`
+* `-h`, `-?`, `--help`, `-H`: `--usage`
+* `-s`, `--silent`: `--loglevel silent`
+* `-q`, `--quiet`: `--loglevel warn`
+* `-d`: `--loglevel info`
+* `-dd`, `--verbose`: `--loglevel verbose`
+* `-ddd`: `--loglevel silly`
+* `-g`: `--global`
+* `-C`: `--prefix`
+* `-l`: `--long`
+* `-m`: `--message`
+* `-p`, `--porcelain`: `--parseable`
+* `-reg`: `--registry`
+* `-f`: `--force`
+* `-desc`: `--description`
+* `-S`: `--save`
+* `-D`: `--save-dev`
+* `-O`: `--save-optional`
+* `-B`: `--save-bundle`
+* `-E`: `--save-exact`
+* `-y`: `--yes`
+* `-n`: `--yes false`
+* `ll` and `la` commands: `ls --long`
+
+If the specified configuration param resolves unambiguously to a known
+configuration parameter, then it is expanded to that configuration
+parameter.  For example:
+
+    npm ls --par
+    # same as:
+    npm ls --parseable
+
+If multiple single-character shorthands are strung together, and the
+resulting combination is unambiguously not some other configuration
+param, then it is expanded to its various component pieces.  For
+example:
+
+    npm ls -gpld
+    # same as:
+    npm ls --global --parseable --long --loglevel info
+
+## Per-Package Config Settings
+
+When running scripts (see `npm-scripts(7)`) the package.json "config"
+keys are overwritten in the environment if there is a config param of
+`<name>[@<version>]:<key>`.  For example, if the package.json has
+this:
+
+    { "name" : "foo"
+    , "config" : { "port" : "8080" }
+    , "scripts" : { "start" : "node server.js" } }
+
+and the server.js is this:
+
+    http.createServer(...).listen(process.env.npm_package_config_port)
+
+then the user could change the behavior by doing:
+
+    npm config set foo:port 80
+
+See package.json(5) for more information.
+
+## Config Settings
+
+### access
+
+* Default: `restricted`
+* Type: Access
+
+When publishing scoped packages, the access level defaults to `restricted`.  If
+you want your scoped package to be publicly viewable (and installable) set
+`--access=public`. The only valid values for `access` are `public` and
+`restricted`. Unscoped packages _always_ have an access level of `public`.
+
+### always-auth
+
+* Default: false
+* Type: Boolean
+
+Force npm to always require authentication when accessing the registry,
+even for `GET` requests.
+
+### bin-links
+
+* Default: `true`
+* Type: Boolean
+
+Tells npm to create symlinks (or `.cmd` shims on Windows) for package
+executables.
+
+Set to false to have it not do this.  This can be used to work around
+the fact that some file systems don't support symlinks, even on
+ostensibly Unix systems.
+
+### browser
+
+* Default: OS X: `"open"`, Windows: `"start"`, Others: `"xdg-open"`
+* Type: String
+
+The browser that is called by the `npm docs` command to open websites.
+
+### ca
+
+* Default: The npm CA certificate
+* Type: String, Array or null
+
+The Certificate Authority signing certificate that is trusted for SSL
+connections to the registry. Values should be in PEM format with newlines
+replaced by the string "\n". For example:
+
+    ca="-----BEGIN CERTIFICATE-----\nXXXX\nXXXX\n-----END CERTIFICATE-----"
+
+Set to `null` to only allow "known" registrars, or to a specific CA cert
+to trust only that specific signing authority.
+
+Multiple CAs can be trusted by specifying an array of certificates:
+
+    ca[]="..."
+    ca[]="..."
+
+See also the `strict-ssl` config.
+
+### cafile
+
+* Default: `null`
+* Type: path
+
+A path to a file containing one or multiple Certificate Authority signing
+certificates. Similar to the `ca` setting, but allows for multiple CA's, as
+well as for the CA information to be stored in a file on disk.
+
+### cache
+
+* Default: Windows: `%AppData%\npm-cache`, Posix: `~/.npm`
+* Type: path
+
+The location of npm's cache directory.  See `npm-cache(1)`
+
+### cache-lock-stale
+
+* Default: 60000 (1 minute)
+* Type: Number
+
+The number of ms before cache folder lockfiles are considered stale.
+
+### cache-lock-retries
+
+* Default: 10
+* Type: Number
+
+Number of times to retry to acquire a lock on cache folder lockfiles.
+
+### cache-lock-wait
+
+* Default: 10000 (10 seconds)
+* Type: Number
+
+Number of ms to wait for cache lock files to expire.
+
+### cache-max
+
+* Default: Infinity
+* Type: Number
+
+The maximum time (in seconds) to keep items in the registry cache before
+re-checking against the registry.
+
+Note that no purging is done unless the `npm cache clean` command is
+explicitly used, and that only GET requests use the cache.
+
+### cache-min
+
+* Default: 10
+* Type: Number
+
+The minimum time (in seconds) to keep items in the registry cache before
+re-checking against the registry.
+
+Note that no purging is done unless the `npm cache clean` command is
+explicitly used, and that only GET requests use the cache.
+
+### cert
+
+* Default: `null`
+* Type: String
+
+A client certificate to pass when accessing the registry.  Values should be in
+PEM format with newlines replaced by the string "\n". For example:
+
+    cert="-----BEGIN CERTIFICATE-----\nXXXX\nXXXX\n-----END CERTIFICATE-----"
+
+It is _not_ the path to a certificate file (and there is no "certfile" option).
+
+### color
+
+* Default: true
+* Type: Boolean or `"always"`
+
+If false, never shows colors.  If `"always"` then always shows colors.
+If true, then only prints color codes for tty file descriptors.
+
+### depth
+
+* Default: Infinity
+* Type: Number
+
+The depth to go when recursing directories for `npm ls`,
+`npm cache ls`, and `npm outdated`.
+
+For `npm outdated`, a setting of `Infinity` will be treated as `0`
+since that gives more useful information.  To show the outdated status
+of all packages and dependents, use a large integer value,
+e.g., `npm outdated --depth 9999`
+
+### description
+
+* Default: true
+* Type: Boolean
+
+Show the description in `npm search`
+
+### dev
+
+* Default: false
+* Type: Boolean
+
+Install `dev-dependencies` along with packages.
+
+Note that `dev-dependencies` are also installed if the `npat` flag is
+set.
+
+### editor
+
+* Default: `EDITOR` environment variable if set, or `"vi"` on Posix,
+  or `"notepad"` on Windows.
+* Type: path
+
+The command to run for `npm edit` or `npm config edit`.
+
+### engine-strict
+
+* Default: false
+* Type: Boolean
+
+If set to true, then npm will stubbornly refuse to install (or even
+consider installing) any package that claims to not be compatible with
+the current Node.js version.
+
+### force
+
+* Default: false
+* Type: Boolean
+
+Makes various commands more forceful.
+
+* lifecycle script failure does not block progress.
+* publishing clobbers previously published versions.
+* skips cache when requesting from the registry.
+* prevents checks against clobbering non-npm files.
+
+### fetch-retries
+
+* Default: 2
+* Type: Number
+
+The "retries" config for the `retry` module to use when fetching
+packages from the registry.
+
+### fetch-retry-factor
+
+* Default: 10
+* Type: Number
+
+The "factor" config for the `retry` module to use when fetching
+packages.
+
+### fetch-retry-mintimeout
+
+* Default: 10000 (10 seconds)
+* Type: Number
+
+The "minTimeout" config for the `retry` module to use when fetching
+packages.
+
+### fetch-retry-maxtimeout
+
+* Default: 60000 (1 minute)
+* Type: Number
+
+The "maxTimeout" config for the `retry` module to use when fetching
+packages.
+
+### git
+
+* Default: `"git"`
+* Type: String
+
+The command to use for git commands.  If git is installed on the
+computer, but is not in the `PATH`, then set this to the full path to
+the git binary.
+
+### git-tag-version
+
+* Default: `true`
+* Type: Boolean
+
+Tag the commit when using the `npm version` command.
+
+### global
+
+* Default: false
+* Type: Boolean
+
+Operates in "global" mode, so that packages are installed into the
+`prefix` folder instead of the current working directory.  See
+`npm-folders(5)` for more on the differences in behavior.
+
+* packages are installed into the `{prefix}/lib/node_modules` folder, instead of the
+  current working directory.
+* bin files are linked to `{prefix}/bin`
+* man pages are linked to `{prefix}/share/man`
+
+### globalconfig
+
+* Default: {prefix}/etc/npmrc
+* Type: path
+
+The config file to read for global config options.
+
+### group
+
+* Default: GID of the current process
+* Type: String or Number
+
+The group to use when running package scripts in global mode as the root
+user.
+
+### heading
+
+* Default: `"npm"`
+* Type: String
+
+The string that starts all the debugging log output.
+
+### https-proxy
+
+* Default: null
+* Type: url
+
+A proxy to use for outgoing https requests. If the `HTTPS_PROXY` or
+`https_proxy` or `HTTP_PROXY` or `http_proxy` environment variables are set,
+proxy settings will be honored by the underlying `request` library.
+
+### if-present
+
+* Default: false
+* Type: Boolean
+
+If true, npm will not exit with an error code when `run-script` is invoked for
+a script that isn't defined in the `scripts` section of `package.json`. This
+option can be used when it's desirable to optionally run a script when it's
+present and fail if the script fails. This is useful, for example, when running
+scripts that may only apply for some builds in an otherwise generic CI setup.
+
+### ignore-scripts
+
+* Default: false
+* Type: Boolean
+
+If true, npm does not run scripts specified in package.json files.
+
+### init-module
+
+* Default: ~/.npm-init.js
+* Type: path
+
+A module that will be loaded by the `npm init` command.  See the
+documentation for the
+[init-package-json](https://github.com/isaacs/init-package-json) module
+for more information, or npm-init(1).
+
+### init-author-name
+
+* Default: ""
+* Type: String
+
+The value `npm init` should use by default for the package author's name.
+
+### init-author-email
+
+* Default: ""
+* Type: String
+
+The value `npm init` should use by default for the package author's email.
+
+### init-author-url
+
+* Default: ""
+* Type: String
+
+The value `npm init` should use by default for the package author's homepage.
+
+### init-license
+
+* Default: "ISC"
+* Type: String
+
+The value `npm init` should use by default for the package license.
+
+### init-version
+
+* Default: "1.0.0"
+* Type: semver
+
+The value that `npm init` should use by default for the package
+version number, if not already set in package.json.
+
+### json
+
+* Default: false
+* Type: Boolean
+
+Whether or not to output JSON data, rather than the normal output.
+
+This feature is currently experimental, and the output data structures
+for many commands is either not implemented in JSON yet, or subject to
+change.  Only the output from `npm ls --json` is currently valid.
+
+### key
+
+* Default: `null`
+* Type: String
+
+A client key to pass when accessing the registry.  Values should be in PEM
+format with newlines replaced by the string "\n". For example:
+
+    key="-----BEGIN PRIVATE KEY-----\nXXXX\nXXXX\n-----END PRIVATE KEY-----"
+
+It is _not_ the path to a key file (and there is no "keyfile" option).
+
+### link
+
+* Default: false
+* Type: Boolean
+
+If true, then local installs will link if there is a suitable globally
+installed package.
+
+Note that this means that local installs can cause things to be
+installed into the global space at the same time.  The link is only done
+if one of the two conditions are met:
+
+* The package is not already installed globally, or
+* the globally installed version is identical to the version that is
+  being installed locally.
+
+### local-address
+
+* Default: undefined
+* Type: IP Address
+
+The IP address of the local interface to use when making connections
+to the npm registry.  Must be IPv4 in versions of Node prior to 0.12.
+
+### loglevel
+
+* Default: "warn"
+* Type: String
+* Values: "silent", "error", "warn", "http", "info", "verbose", "silly"
+
+What level of logs to report.  On failure, *all* logs are written to
+`npm-debug.log` in the current working directory.
+
+Any logs of a higher level than the setting are shown.
+The default is "warn", which shows warn and error output.
+
+### logstream
+
+* Default: process.stderr
+* Type: Stream
+
+This is the stream that is passed to the
+[npmlog](https://github.com/npm/npmlog) module at run time.
+
+It cannot be set from the command line, but if you are using npm
+programmatically, you may wish to send logs to somewhere other than
+stderr.
+
+If the `color` config is set to true, then this stream will receive
+colored output if it is a TTY.
+
+### long
+
+* Default: false
+* Type: Boolean
+
+Show extended information in `npm ls` and `npm search`.
+
+### maxsockets
+
+* Default: 50
+* Type: Number
+
+The maximum number of connections to use per origin (protocol/host/port
+combination). Passed to the `http` `Agent` used to make the request.
+
+### message
+
+* Default: "%s"
+* Type: String
+
+Commit message which is used by `npm version` when creating version commit.
+
+Any "%s" in the message will be replaced with the version number.
+
+### node-version
+
+* Default: process.version
+* Type: semver or false
+
+The node version to use when checking a package's `engines` map.
+
+### npat
+
+* Default: false
+* Type: Boolean
+
+Run tests on installation.
+
+### onload-script
+
+* Default: false
+* Type: path
+
+A node module to `require()` when npm loads.  Useful for programmatic
+usage.
+
+### optional
+
+* Default: true
+* Type: Boolean
+
+Attempt to install packages in the `optionalDependencies` object.  Note
+that if these packages fail to install, the overall installation
+process is not aborted.
+
+### parseable
+
+* Default: false
+* Type: Boolean
+
+Output parseable results from commands that write to
+standard output.
+
+### prefix
+
+* Default: see npm-folders(5)
+* Type: path
+
+The location to install global items.  If set on the command line, then
+it forces non-global commands to run in the specified folder.
+
+### production
+
+* Default: false
+* Type: Boolean
+
+Set to true to run in "production" mode.
+
+1. devDependencies are not installed at the topmost level when running
+   local `npm install` without any arguments.
+2. Set the NODE_ENV="production" for lifecycle scripts.
+
+### proprietary-attribs
+
+* Default: true
+* Type: Boolean
+
+Whether or not to include proprietary extended attributes in the
+tarballs created by npm.
+
+Unless you are expecting to unpack package tarballs with something other
+than npm -- particularly a very outdated tar implementation -- leave
+this as true.
+
+### proxy
+
+* Default: null
+* Type: url
+
+A proxy to use for outgoing http requests. If the `HTTP_PROXY` or
+`http_proxy` environment variables are set, proxy settings will be
+honored by the underlying `request` library.
+
+### rebuild-bundle
+
+* Default: true
+* Type: Boolean
+
+Rebuild bundled dependencies after installation.
+
+### registry
+
+* Default: https://registry.npmjs.org/
+* Type: url
+
+The base URL of the npm package registry.
+
+### rollback
+
+* Default: true
+* Type: Boolean
+
+Remove failed installs.
+
+### save
+
+* Default: false
+* Type: Boolean
+
+Save installed packages to a package.json file as dependencies.
+
+When used with the `npm rm` command, it removes it from the `dependencies`
+object.
+
+Only works if there is already a package.json file present.
+
+### save-bundle
+
+* Default: false
+* Type: Boolean
+
+If a package would be saved at install time by the use of `--save`,
+`--save-dev`, or `--save-optional`, then also put it in the
+`bundleDependencies` list.
+
+When used with the `npm rm` command, it removes it from the
+bundledDependencies list.
+
+### save-dev
+
+* Default: false
+* Type: Boolean
+
+Save installed packages to a package.json file as `devDependencies`.
+
+When used with the `npm rm` command, it removes it from the
+`devDependencies` object.
+
+Only works if there is already a package.json file present.
+
+### save-exact
+
+* Default: false
+* Type: Boolean
+
+Dependencies saved to package.json using `--save`, `--save-dev` or
+`--save-optional` will be configured with an exact version rather than
+using npm's default semver range operator.
+
+### save-optional
+
+* Default: false
+* Type: Boolean
+
+Save installed packages to a package.json file as
+optionalDependencies.
+
+When used with the `npm rm` command, it removes it from the
+`devDependencies` object.
+
+Only works if there is already a package.json file present.
+
+### save-prefix
+
+* Default: '^'
+* Type: String
+
+Configure how versions of packages installed to a package.json file via
+`--save` or `--save-dev` get prefixed.
+
+For example if a package has version `1.2.3`, by default its version is
+set to `^1.2.3` which allows minor upgrades for that package, but after
+`npm config set save-prefix='~'` it would be set to `~1.2.3` which only allows
+patch upgrades.
+
+### scope
+
+* Default: ""
+* Type: String
+
+Associate an operation with a scope for a scoped registry. Useful when logging
+in to a private registry for the first time:
+`npm login --scope=@organization --registry=registry.organization.com`, which
+will cause `@organization` to be mapped to the registry for future installation
+of packages specified according to the pattern `@organization/package`.
+
+### searchopts
+
+* Default: ""
+* Type: String
+
+Space-separated options that are always passed to search.
+
+### searchexclude
+
+* Default: ""
+* Type: String
+
+Space-separated options that limit the results from search.
+
+### searchsort
+
+* Default: "name"
+* Type: String
+* Values: "name", "-name", "date", "-date", "description",
+  "-description", "keywords", "-keywords"
+
+Indication of which field to sort search results by.  Prefix with a `-`
+character to indicate reverse sort.
+
+### shell
+
+* Default: SHELL environment variable, or "bash" on Posix, or "cmd" on
+  Windows
+* Type: path
+
+The shell to run for the `npm explore` command.
+
+### shrinkwrap
+
+* Default: true
+* Type: Boolean
+
+If set to false, then ignore `npm-shrinkwrap.json` files when
+installing.
+
+### sign-git-tag
+
+* Default: false
+* Type: Boolean
+
+If set to true, then the `npm version` command will tag the version
+using `-s` to add a signature.
+
+Note that git requires you to have set up GPG keys in your git configs
+for this to work properly.
+
+### spin
+
+* Default: true
+* Type: Boolean or `"always"`
+
+When set to `true`, npm will display an ascii spinner while it is doing
+things, if `process.stderr` is a TTY.
+
+Set to `false` to suppress the spinner, or set to `always` to output
+the spinner even for non-TTY outputs.
+
+### strict-ssl
+
+* Default: true
+* Type: Boolean
+
+Whether or not to do SSL key validation when making requests to the
+registry via https.
+
+See also the `ca` config.
+
+### tag
+
+* Default: latest
+* Type: String
+
+If you ask npm to install a package and don't tell it a specific version, then
+it will install the specified tag.
+
+Also the tag that is added to the package@version specified by the `npm
+tag` command, if no explicit tag is given.
+
+### tag-version-prefix
+
+* Default: `"v"`
+* Type: String
+
+If set, alters the prefix used when tagging a new version when performing a
+version increment using  `npm-version`. To remove the prefix altogether, set it
+to the empty string: `""`.
+
+Because other tools may rely on the convention that npm version tags look like
+`v1.0.0`, _only use this property if it is absolutely necessary_. In
+particular, use care when overriding this setting for public packages.
+
+### tmp
+
+* Default: TMPDIR environment variable, or "/tmp"
+* Type: path
+
+Where to store temporary files and folders.  All temp files are deleted
+on success, but left behind on failure for forensic purposes.
+
+### unicode
+
+* Default: true
+* Type: Boolean
+
+When set to true, npm uses unicode characters in the tree output.  When
+false, it uses ascii characters to draw trees.
+
+### unsafe-perm
+
+* Default: false if running as root, true otherwise
+* Type: Boolean
+
+Set to true to suppress the UID/GID switching when running package
+scripts.  If set explicitly to false, then installing as a non-root user
+will fail.
+
+### usage
+
+* Default: false
+* Type: Boolean
+
+Set to show short usage output (like the -H output)
+instead of complete help when doing `npm-help(1)`.
+
+### user
+
+* Default: "nobody"
+* Type: String or Number
+
+The UID to set to when running package scripts as root.
+
+### userconfig
+
+* Default: ~/.npmrc
+* Type: path
+
+The location of user-level configuration settings.
+
+### umask
+
+* Default: 022
+* Type: Octal numeric string in range 0000..0777 (0..511)
+
+The "umask" value to use when setting the file creation mode on files
+and folders.
+
+Folders and executables are given a mode which is `0777` masked against
+this value.  Other files are given a mode which is `0666` masked against
+this value.  Thus, the defaults are `0755` and `0644` respectively.
+
+### user-agent
+
+* Default: node/{process.version} {process.platform} {process.arch}
+* Type: String
+
+Sets a User-Agent to the request header
+
+### version
+
+* Default: false
+* Type: boolean
+
+If true, output the npm version and exit successfully.
+
+Only relevant when specified explicitly on the command line.
+
+### versions
+
+* Default: false
+* Type: boolean
+
+If true, output the npm version as well as node's `process.versions` map, and
+exit successfully.
+
+Only relevant when specified explicitly on the command line.
+
+### viewer
+
+* Default: "man" on Posix, "browser" on Windows
+* Type: path
+
+The program to use to view help content.
+
+Set to `"browser"` to view html help content in the default web browser.
+
+## SEE ALSO
+
+* npm-config(1)
+* npmrc(5)
+* npm-scripts(7)
+* npm-folders(5)
+* npm(1)

node_modules/npm/doc/misc/npm-developers.md

@@ -0,0 +1,221 @@
+npm-developers(7) -- Developer Guide
+====================================
+
+## DESCRIPTION
+
+So, you've decided to use npm to develop (and maybe publish/deploy)
+your project.
+
+Fantastic!
+
+There are a few things that you need to do above the simple steps
+that your users will do to install your program.
+
+## About These Documents
+
+These are man pages.  If you install npm, you should be able to
+then do `man npm-thing` to get the documentation on a particular
+topic, or `npm help thing` to see the same information.
+
+## What is a `package`
+
+A package is:
+
+* a) a folder containing a program described by a package.json file
+* b) a gzipped tarball containing (a)
+* c) a url that resolves to (b)
+* d) a `<name>@<version>` that is published on the registry with (c)
+* e) a `<name>@<tag>` that points to (d)
+* f) a `<name>` that has a "latest" tag satisfying (e)
+* g) a `git` url that, when cloned, results in (a).
+
+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).
+
+Git urls can be of the form:
+
+    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
+
+The `commit-ish` can be any tag, sha, or branch which can be supplied as
+an argument to `git checkout`.  The default is `master`.
+
+## The package.json File
+
+You need to have a `package.json` file in the root of your project to do
+much of anything with npm.  That is basically the whole interface.
+
+See `package.json(5)` for details about what goes in that file.  At the very
+least, you need:
+
+* 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, `node-foo` and `bar-js` are bad names.  `foo` or `bar` are better.
+
+* version:
+  A semver-compatible version.
+
+* 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.
+
+* author:
+  Take some credit.
+
+* scripts:
+  If you have a special compilation or installation script, then you
+  should put it in the `scripts` object.  You should definitely have at
+  least a basic smoke-test command as the "scripts.test" field.
+  See npm-scripts(7).
+
+* 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.
+
+* 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.
+
+You can use `npm init` in the root of your package in order to get you
+started with a pretty basic package.json file.  See `npm-init(1)` for
+more info.
+
+## Keeping files *out* of your package
+
+Use a `.npmignore` file to keep stuff out of your package.  If there's
+no `.npmignore` file, but there *is* a `.gitignore` file, then npm will
+ignore the stuff matched by the `.gitignore` file.  If you *want* to
+include something that is excluded by your `.gitignore` file, you can
+create an empty `.npmignore` file to override it. Like `git`, `npm` looks
+for `.npmignore` and `.gitignore` files in all subdirectories of your
+package, not only the root directory.
+
+`.npmignore` files follow the [same pattern rules](https://git-scm.com/book/en/v2/Git-Basics-Recording-Changes-to-the-Repository#Ignoring-Files)
+as `.gitignore` files:
+
+* Blank lines or lines starting with `#` are ignored.
+* Standard glob patterns work.
+* You can end patterns with a forward slash `/` to specify a directory.
+* You can negate a pattern by starting it with an exclamation point `!`.
+
+By default, the following paths and files are ignored, so there's no
+need to add them to `.npmignore` explicitly:
+
+* `.*.swp`
+* `._*`
+* `.DS_Store`
+* `.git`
+* `.hg`
+* `.npmrc`
+* `.lock-wscript`
+* `.svn`
+* `.wafpickle-*`
+* `config.gypi`
+* `CVS`
+* `npm-debug.log`
+
+Additionally, everything in `node_modules` is ignored, except for
+bundled dependencies. npm automatically handles this for you, so don't
+bother adding `node_modules` to `.npmignore`.
+
+The following paths and files are never ignored, so adding them to
+`.npmignore` is pointless:
+
+* `package.json`
+* `README` (and its variants)
+* `CHANGELOG` (and its variants)
+* `LICENSE` / `LICENCE`
+
+## Link Packages
+
+`npm link` 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 `npm rebuild -g` to update compiled packages,
+of course.)
+
+More info at `npm-link(1)`.
+
+## Before Publishing: Make Sure Your Package Installs and Works
+
+**This is important.**
+
+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.
+
+In the root of your package, do this:
+
+    npm install . -g
+
+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:
+
+    npm link
+
+Use `npm ls -g` to see if it's there.
+
+To test a local install, go into some other folder, and then do:
+
+    cd ../some-other-folder
+    npm install ../my-package
+
+to install it locally into the node_modules folder in that other place.
+
+Then go into the node-repl, and try using require("my-thing") to
+bring in your module's main module.
+
+## Create a User Account
+
+Create a user with the adduser command.  It works like this:
+
+    npm adduser
+
+and then follow the prompts.
+
+This is documented better in npm-adduser(1).
+
+## Publish your package
+
+This part's easy.  In the root of your folder, do this:
+
+    npm publish
+
+You can give publish a url to a tarball, or a filename of a tarball,
+or a path to a folder.
+
+Note that pretty much **everything in that folder will be exposed**
+by default.  So, if you have secret stuff in there, use a
+`.npmignore` file to list out the globs to ignore, or publish
+from a fresh checkout.
+
+## Brag about it
+
+Send emails, write blogs, blab in IRC.
+
+Tell the world how easy it is to install your program!
+
+## SEE ALSO
+
+* npm-faq(7)
+* npm(1)
+* npm-init(1)
+* package.json(5)
+* npm-scripts(7)
+* npm-publish(1)
+* npm-adduser(1)
+* npm-registry(7)

node_modules/npm/doc/misc/npm-disputes.md

@@ -0,0 +1,99 @@
+npm-disputes(7) -- Handling Module Name Disputes
+================================================
+
+## SYNOPSIS
+
+1. Get the author email with `npm owner ls <pkgname>`
+2. Email the author, CC <support@npmjs.com>
+3. After a few weeks, if there's no resolution, we'll sort it out.
+
+Don't squat on package names.  Publish code or move out of the way.
+
+## DESCRIPTION
+
+There sometimes arise cases where a user publishes a module, and then
+later, some other user wants to use that name.  Here are some common
+ways that happens (each of these is based on actual events.)
+
+1. Joe writes a JavaScript module `foo`, which is not node-specific.
+   Joe doesn't use node at all.  Bob   wants to use `foo` in node, so he
+   wraps it in an npm module.  Some time later, Joe starts using node,
+   and wants to take over management of his program.
+2. Bob writes an npm module `foo`, and publishes it.  Perhaps much
+   later, Joe finds a bug in `foo`, and fixes it.  He sends a pull
+   request to Bob, but Bob doesn't have the time to deal with it,
+   because he has a new job and a new baby and is focused on his new
+   erlang project, and kind of not involved with node any more.  Joe
+   would like to publish a new `foo`, but can't, because the name is
+   taken.
+3. Bob writes a 10-line flow-control library, and calls it `foo`, and
+   publishes it to the npm registry.  Being a simple little thing, it
+   never really has to be updated.  Joe works for Foo Inc, the makers
+   of the critically acclaimed and widely-marketed `foo` JavaScript
+   toolkit framework.  They publish it to npm as `foojs`, but people are
+   routinely confused when `npm install foo` is some different thing.
+4. Bob writes a parser for the widely-known `foo` file format, because
+   he needs it for work.  Then, he gets a new job, and never updates the
+   prototype.  Later on, Joe writes a much more complete `foo` parser,
+   but can't publish, because Bob's `foo` is in the way.
+
+The validity of Joe's claim in each situation can be debated.  However,
+Joe's appropriate course of action in each case is the same.
+
+1. `npm owner ls foo`.  This will tell Joe the email address of the
+   owner (Bob).
+2. Joe emails Bob, explaining the situation **as respectfully as
+   possible**, and what he would like to do with the module name.  He
+   adds the npm support staff <support@npmjs.com> to the CC list of
+   the email.  Mention in the email that Bob can run `npm owner add
+   joe foo` to add Joe as an owner of the `foo` package.
+3. After a reasonable amount of time, if Bob has not responded, or if
+   Bob and Joe can't come to any sort of resolution, email support
+   <support@npmjs.com> and we'll sort it out.  ("Reasonable" is
+   usually at least 4 weeks, but extra time is allowed around common
+   holidays.)
+
+## REASONING
+
+In almost every case so far, the parties involved have been able to reach
+an amicable resolution without any major intervention.  Most people
+really do want to be reasonable, and are probably not even aware that
+they're in your way.
+
+Module ecosystems are most vibrant and powerful when they are as
+self-directed as possible.  If an admin one day deletes something you
+had worked on, then that is going to make most people quite upset,
+regardless of the justification.  When humans solve their problems by
+talking to other humans with respect, everyone has the chance to end up
+feeling good about the interaction.
+
+## EXCEPTIONS
+
+Some things are not allowed, and will be removed without discussion if
+they are brought to the attention of the npm registry admins, including
+but not limited to:
+
+1. Malware (that is, a package designed to exploit or harm the machine on
+   which it is installed).
+2. Violations of copyright or licenses (for example, cloning an
+   MIT-licensed program, and then removing or changing the copyright and
+   license statement).
+3. Illegal content.
+4. "Squatting" on a package name that you *plan* to use, but aren't
+   actually using.  Sorry, I don't care how great the name is, or how
+   perfect a fit it is for the thing that someday might happen.  If
+   someone wants to use it today, and you're just taking up space with
+   an empty tarball, you're going to be evicted.
+5. Putting empty packages in the registry.  Packages must have SOME
+   functionality.  It can be silly, but it can't be *nothing*.  (See
+   also: squatting.)
+6. Doing weird things with the registry, like using it as your own
+   personal application database or otherwise putting non-packagey
+   things into it.
+
+If you see bad behavior like this, please report it right away.
+
+## SEE ALSO
+
+* npm-registry(7)
+* npm-owner(1)

node_modules/npm/doc/misc/npm-index.md

@@ -0,0 +1,443 @@
+npm-index(7) -- Index of all npm documentation
+==============================================
+
+### README(1)
+
+a JavaScript package manager
+
+## Command Line Documentation
+
+Using npm on the command line
+
+### npm(1)
+
+javascript package manager
+
+### npm-access(1)
+
+Set access level on published packages
+
+### npm-adduser(1)
+
+Add a registry user account
+
+### npm-bin(1)
+
+Display npm bin folder
+
+### npm-bugs(1)
+
+Bugs for a package in a web browser maybe
+
+### npm-build(1)
+
+Build a package
+
+### npm-bundle(1)
+
+REMOVED
+
+### npm-cache(1)
+
+Manipulates packages cache
+
+### npm-completion(1)
+
+Tab Completion for npm
+
+### npm-config(1)
+
+Manage the npm configuration files
+
+### npm-dedupe(1)
+
+Reduce duplication
+
+### npm-deprecate(1)
+
+Deprecate a version of a package
+
+### npm-dist-tag(1)
+
+Modify package distribution tags
+
+### npm-docs(1)
+
+Docs for a package in a web browser maybe
+
+### npm-edit(1)
+
+Edit an installed package
+
+### npm-explore(1)
+
+Browse an installed package
+
+### npm-help-search(1)
+
+Search npm help documentation
+
+### npm-help(1)
+
+Get help on npm
+
+### npm-init(1)
+
+Interactively create a package.json file
+
+### npm-install(1)
+
+Install a package
+
+### npm-link(1)
+
+Symlink a package folder
+
+### npm-logout(1)
+
+Log out of the registry
+
+### npm-ls(1)
+
+List installed packages
+
+### npm-outdated(1)
+
+Check for outdated packages
+
+### npm-owner(1)
+
+Manage package owners
+
+### npm-pack(1)
+
+Create a tarball from a package
+
+### npm-ping(1)
+
+Ping npm registry
+
+### npm-prefix(1)
+
+Display prefix
+
+### npm-prune(1)
+
+Remove extraneous packages
+
+### npm-publish(1)
+
+Publish a package
+
+### npm-rebuild(1)
+
+Rebuild a package
+
+### npm-repo(1)
+
+Open package repository page in the browser
+
+### npm-restart(1)
+
+Restart a package
+
+### npm-rm(1)
+
+Remove a package
+
+### npm-root(1)
+
+Display npm root
+
+### npm-run-script(1)
+
+Run arbitrary package scripts
+
+### npm-search(1)
+
+Search for packages
+
+### npm-shrinkwrap(1)
+
+Lock down dependency versions
+
+### npm-star(1)
+
+Mark your favorite packages
+
+### npm-stars(1)
+
+View packages marked as favorites
+
+### npm-start(1)
+
+Start a package
+
+### npm-stop(1)
+
+Stop a package
+
+### npm-tag(1)
+
+Tag a published version
+
+### npm-team(1)
+
+Manage organization teams and team memberships
+
+### npm-test(1)
+
+Test a package
+
+### npm-uninstall(1)
+
+Remove a package
+
+### npm-unpublish(1)
+
+Remove a package from the registry
+
+### npm-update(1)
+
+Update a package
+
+### npm-version(1)
+
+Bump a package version
+
+### npm-view(1)
+
+View registry info
+
+### npm-whoami(1)
+
+Display npm username
+
+## API Documentation
+
+Using npm in your Node programs
+
+### npm(3)
+
+javascript package manager
+
+### npm-bin(3)
+
+Display npm bin folder
+
+### npm-bugs(3)
+
+Bugs for a package in a web browser maybe
+
+### npm-cache(3)
+
+manage the npm cache programmatically
+
+### npm-commands(3)
+
+npm commands
+
+### npm-config(3)
+
+Manage the npm configuration files
+
+### npm-deprecate(3)
+
+Deprecate a version of a package
+
+### npm-docs(3)
+
+Docs for a package in a web browser maybe
+
+### npm-edit(3)
+
+Edit an installed package
+
+### npm-explore(3)
+
+Browse an installed package
+
+### npm-help-search(3)
+
+Search the help pages
+
+### npm-init(3)
+
+Interactively create a package.json file
+
+### npm-install(3)
+
+install a package programmatically
+
+### npm-link(3)
+
+Symlink a package folder
+
+### npm-load(3)
+
+Load config settings
+
+### npm-ls(3)
+
+List installed packages
+
+### npm-outdated(3)
+
+Check for outdated packages
+
+### npm-owner(3)
+
+Manage package owners
+
+### npm-pack(3)
+
+Create a tarball from a package
+
+### npm-ping(3)
+
+Ping npm registry
+
+### npm-prefix(3)
+
+Display prefix
+
+### npm-prune(3)
+
+Remove extraneous packages
+
+### npm-publish(3)
+
+Publish a package
+
+### npm-rebuild(3)
+
+Rebuild a package
+
+### npm-repo(3)
+
+Open package repository page in the browser
+
+### npm-restart(3)
+
+Restart a package
+
+### npm-root(3)
+
+Display npm root
+
+### npm-run-script(3)
+
+Run arbitrary package scripts
+
+### npm-search(3)
+
+Search for packages
+
+### npm-shrinkwrap(3)
+
+programmatically generate package shrinkwrap file
+
+### npm-start(3)
+
+Start a package
+
+### npm-stop(3)
+
+Stop a package
+
+### npm-tag(3)
+
+Tag a published version
+
+### npm-test(3)
+
+Test a package
+
+### npm-uninstall(3)
+
+uninstall a package programmatically
+
+### npm-unpublish(3)
+
+Remove a package from the registry
+
+### npm-update(3)
+
+Update a package
+
+### npm-version(3)
+
+Bump a package version
+
+### npm-view(3)
+
+View registry info
+
+### npm-whoami(3)
+
+Display npm username
+
+## Files
+
+File system structures npm uses
+
+### npm-folders(5)
+
+Folder Structures Used by npm
+
+### npmrc(5)
+
+The npm config files
+
+### package.json(5)
+
+Specifics of npm's package.json handling
+
+## Misc
+
+Various other bits and bobs
+
+### npm-coding-style(7)
+
+npm's "funny" coding style
+
+### npm-config(7)
+
+More than you probably want to know about npm configuration
+
+### npm-developers(7)
+
+Developer Guide
+
+### npm-disputes(7)
+
+Handling Module Name Disputes
+
+### npm-index(7)
+
+Index of all npm documentation
+
+### npm-orgs(7)
+
+Working with Teams & Orgs
+
+### npm-registry(7)
+
+The JavaScript Package Registry
+
+### npm-scope(7)
+
+Scoped packages
+
+### npm-scripts(7)
+
+How npm handles the "scripts" field
+
+### removing-npm(7)
+
+Cleaning the Slate
+
+### semver(7)
+
+The semantic versioner for npm
+

node_modules/npm/doc/misc/npm-orgs.md

@@ -0,0 +1,90 @@
+npm-orgs(7) -- Working with Teams & Orgs
+========================================
+
+## DESCRIPTION
+
+There are three levels of org users:
+
+1. Super admin, controls billing & adding people to the org.
+2. Team admin, manages team membership & package access.
+3. Developer, works on packages they are given access to.  
+
+The super admin is the only person who can add users to the org because it impacts the monthly bill. The super admin will use the website to manage membership. Every org has a `developers` team that all users are automatically added to.
+
+The team admin is the person who manages team creation, team membership, and package access for teams. The team admin grants package access to teams, not individuals.
+
+The developer will be able to access packages based on the teams they are on. Access is either read-write or read-only.
+
+There are two main commands:
+
+1. `npm team` see npm-team(1) for more details
+2. `npm access` see npm-access(1) for more details
+
+## Team Admins create teams
+
+* Check who you’ve added to your org:
+
+```
+npm team ls <org>:developers
+```
+
+* Each org is automatically given a `developers` team, so you can see the whole list of team members in your org. This team automatically gets read-write access to all packages, but you can change that with the `access` command.
+
+* Create a new team:
+
+```
+npm team create <org:team>
+```
+
+* Add members to that team:
+
+```
+npm team add <org:team> <user>
+```
+
+## Publish a package and adjust package access
+
+* In package directory, run
+
+```
+npm init --scope=<org>
+```
+to scope it for your org & publish as usual
+
+* Grant access:  
+
+```
+npm access grant <read-only|read-write> <org:team> [<package>]
+```
+
+* Revoke access:
+
+```
+npm access revoke <org:team> [<package>]
+```
+
+## Monitor your package access
+
+* See what org packages a team member can access:
+
+```
+npm access ls-packages <org> <user>
+```
+
+* See packages available to a specific team:
+
+```
+npm access ls-packages <org:team>
+```
+
+* Check which teams are collaborating on a package:
+
+```
+npm access ls-collaborators <pkg>
+```
+
+## SEE ALSO
+
+* npm-team(1)
+* npm-access(1)
+* npm-scope(7)