10 files changed, 2575 insertions, 0 deletions
diff --git a/deps/npm/doc/misc/npm-coding-style.md b/deps/npm/doc/misc/npm-coding-style.md
new file mode 100644
index 000000000..e9333d0ec
--- /dev/null
+++ b/deps/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 at npmjs.org
+
+## 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/isaacs/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, members, 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)
diff --git a/deps/npm/doc/misc/npm-config.md b/deps/npm/doc/misc/npm-config.md
new file mode 100644
index 000000000..d622f07e1
--- /dev/null
+++ b/deps/npm/doc/misc/npm-config.md
@@ -0,0 +1,827 @@
+npm-config(7) -- More than you probably want to know about npm configuration
+============================================================================
+
+## DESCRIPTION
+
+npm gets its configuration values from 6 sources, in this 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 three relevant files are:
+
+* per-user config file (~/.npmrc)
+* global config file ($PREFIX/npmrc)
+* npm builtin config 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`
+* `-l`: `--long`
+* `-m`: `--message`
+* `-p`, `--porcelain`: `--parseable`
+* `-reg`: `--registry`
+* `-v`: `--version`
+* `-f`: `--force`
+* `-desc`: `--description`
+* `-S`: `--save`
+* `-D`: `--save-dev`
+* `-O`: `--save-optional`
+* `-B`: `--save-bundle`
+* `-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
+
+### 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 or null
+
+The Certificate Authority signing certificate that is trusted for SSL
+connections to the registry.
+
+Set to `null` to only allow "known" registrars, or to a specific CA cert
+to trust only that specific signing authority.
+
+See also the `strict-ssl` config.
+
+### 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.
+
+### color
+
+* Default: true on Posix, false on Windows
+* 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.
+
+### coverage
+
+* Default: false
+* Type: Boolean
+
+A flag to tell test-harness to run with their coverage options enabled,
+if they respond to the `npm_config_coverage` environment variable.
+
+### depth
+
+* Default: Infinity
+* Type: Number
+
+The depth to go when recursing directories for `npm ls` and
+`npm cache ls`.
+
+### 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.
+
+### 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(7)` 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.
+
+### globalignorefile
+
+* Default: {prefix}/etc/npmignore
+* Type: path
+
+The config file to read for global ignore patterns to apply to all users
+and all projects.
+
+If not found, but there is a "gitignore" file in the
+same directory, then that will be used instead.
+
+### 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.
+
+### https-proxy
+
+* Default: the `HTTPS_PROXY` or `https_proxy` or `HTTP_PROXY` or
+  `http_proxy` environment variables.
+* Type: url
+
+A proxy to use for outgoing https requests.
+
+### user-agent
+
+* Default: node/{process.version} {process.platform} {process.arch}
+* Type: String
+
+Sets a User-Agent to the request header
+
+### ignore
+
+* Default: ""
+* Type: string
+
+A white-space separated list of glob patterns of files to always exclude
+from packages when building tarballs.
+
+### 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.version
+
+* Default: "0.0.0"
+* Type: semver
+
+The value `npm init` should use by default for the package version.
+
+### 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.
+
+### 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.
+
+### 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.
+
+### loglevel
+
+* Default: "http"
+* Type: String
+* Values: "silent", "win", "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 "http", which shows http, warn, and error output.
+
+### logstream
+
+* Default: process.stderr
+* Type: Stream
+
+This is the stream that is passed to the
+[npmlog](https://github.com/isaacs/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`
+
+### 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 package's "engines" hash.
+
+### npat
+
+* Default: false
+* Type: Boolean
+
+Run tests on installation and report results to the
+`npaturl`.
+
+### npaturl
+
+* Default: Not yet implemented
+* Type: url
+
+The url to report npat test results.
+
+### 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` hash.  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(7)
+* 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: `HTTP_PROXY` or `http_proxy` environment variable, or null
+* Type: url
+
+A proxy to use for outgoing http requests.
+
+### 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
+hash.
+
+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
+hash.
+
+Only works if there is already a package.json file present.
+
+### 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
+hash.
+
+Only works if there is already a package.json file present.
+
+### 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.
+
+### 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.
+
+### 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.
+
+### username
+
+* Default: null
+* Type: String
+
+The username on the npm registry.  Set with `npm adduser`
+
+### userconfig
+
+* Default: ~/.npmrc
+* Type: path
+
+The location of user-level configuration settings.
+
+### userignorefile
+
+* Default: ~/.npmignore
+* Type: path
+
+The location of a user-level ignore file to apply to all packages.
+
+If not found, but there is a .gitignore file in the same directory, then
+that will be used instead.
+
+### umask
+
+* Default: 022
+* Type: Octal numeric string
+
+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.
+
+### 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`
+hash, 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.
+
+### yes
+
+* Default: null
+* Type: Boolean or null
+
+If set to `null`, then prompt the user for responses in some
+circumstances.
+
+If set to `true`, then answer "yes" to any prompt.  If set to `false`
+then answer "no" to any prompt.
+
+## SEE ALSO
+
+* npm-config(1)
+* npm-config(7)
+* npmrc(5)
+* npm-scripts(7)
+* npm-folders(5)
+* npm(1)
diff --git a/deps/npm/doc/misc/npm-developers.md b/deps/npm/doc/misc/npm-developers.md
new file mode 100644
index 000000000..5e53301f3
--- /dev/null
+++ b/deps/npm/doc/misc/npm-developers.md
@@ -0,0 +1,207 @@
+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` hash.  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 a hash of folders.  The best ones to include are "lib" and
+  "doc", but if you specify a folder full of man pages in "man", then
+  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.
+
+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`
+* `.lock-wscript`
+* `.svn`
+* `.wafpickle-*`
+* `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.*`
+
+## 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)
diff --git a/deps/npm/doc/misc/npm-disputes.md b/deps/npm/doc/misc/npm-disputes.md
new file mode 100644
index 000000000..6e9f4bfcd
--- /dev/null
+++ b/deps/npm/doc/misc/npm-disputes.md
@@ -0,0 +1,98 @@
+npm-disputes(7) -- Handling Module Name Disputes
+================================================
+
+## SYNOPSIS
+
+1. Get the author email with `npm owner ls <pkgname>`
+2. Email the author, CC <i@izs.me>.
+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
+   isaacs <i@izs.me> 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 isaacs
+   <i@izs.me> and we'll sort it out.  ("Reasonable" is usually about 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)
diff --git a/deps/npm/doc/misc/npm-faq.md b/deps/npm/doc/misc/npm-faq.md
new file mode 100644
index 000000000..32493d36e
--- /dev/null
+++ b/deps/npm/doc/misc/npm-faq.md
@@ -0,0 +1,355 @@
+npm-faq(7) -- Frequently Asked Questions
+========================================
+
+## Where can I find these docs in HTML?
+
+<https://npmjs.org/doc/>, or run:
+
+    npm config set viewer browser
+
+to open these documents in your default web browser rather than `man`.
+
+## It didn't work.
+
+That's not really a question.
+
+## Why didn't it work?
+
+I don't know yet.
+
+Read the error output, and if you can't figure out what it means,
+do what it says and post a bug with all the information it asks for.
+
+## Where does npm put stuff?
+
+See `npm-folders(5)`
+
+tl;dr:
+
+* Use the `npm root` command to see where modules go, and the `npm bin`
+  command to see where executables go
+* Global installs are different from local installs.  If you install
+  something with the `-g` flag, then its executables go in `npm bin -g`
+  and its modules go in `npm root -g`.
+
+## How do I install something on my computer in a central location?
+
+Install it globally by tacking `-g` or `--global` to the command.  (This
+is especially important for command line utilities that need to add
+their bins to the global system `PATH`.)
+
+## I installed something globally, but I can't `require()` it
+
+Install it locally.
+
+The global install location is a place for command-line utilities
+to put their bins in the system `PATH`.  It's not for use with `require()`.
+
+If you `require()` a module in your code, then that means it's a
+dependency, and a part of your program.  You need to install it locally
+in your program.
+
+## Why can't npm just put everything in one place, like other package managers?
+
+Not every change is an improvement, but every improvement is a change.
+This would be like asking git to do network IO for every commit.  It's
+not going to happen, because it's a terrible idea that causes more
+problems than it solves.
+
+It is much harder to avoid dependency conflicts without nesting
+dependencies.  This is fundamental to the way that npm works, and has
+proven to be an extremely successful approach.  See `npm-folders(5)` for
+more details.
+
+If you want a package to be installed in one place, and have all your
+programs reference the same copy of it, then use the `npm link` command.
+That's what it's for.  Install it globally, then link it into each
+program that uses it.
+
+## Whatever, I really want the old style 'everything global' style.
+
+Write your own package manager, then.  It's not that hard.
+
+npm will not help you do something that is known to be a bad idea.
+
+## Should I check my `node_modules` folder into git?
+
+Mikeal Rogers answered this question very well:
+
+<http://www.mikealrogers.com/posts/nodemodules-in-git.html>
+
+tl;dr
+
+* Check `node_modules` into git for things you **deploy**, such as
+  websites and apps.
+* Do not check `node_modules` into git for libraries and modules
+  intended to be reused.
+* Use npm to manage dependencies in your dev environment, but not in
+  your deployment scripts.
+
+## Is it 'npm' or 'NPM' or 'Npm'?
+
+npm should never be capitalized unless it is being displayed in a
+location that is customarily all-caps (such as the title of man pages.)
+
+## If 'npm' is an acronym, why is it never capitalized?
+
+Contrary to the belief of many, "npm" is not in fact an abbreviation for
+"Node Package Manager".  It is a recursive bacronymic abbreviation for
+"npm is not an acronym".  (If it was "ninaa", then it would be an
+acronym, and thus incorrectly named.)
+
+"NPM", however, *is* an acronym (more precisely, a capitonym) for the
+National Association of Pastoral Musicians.  You can learn more
+about them at <http://npm.org/>.
+
+In software, "NPM" is a Non-Parametric Mapping utility written by
+Chris Rorden.  You can analyze pictures of brains with it.  Learn more
+about the (capitalized) NPM program at <http://www.cabiatl.com/mricro/npm/>.
+
+The first seed that eventually grew into this flower was a bash utility
+named "pm", which was a shortened descendent of "pkgmakeinst", a
+bash function that was used to install various different things on different
+platforms, most often using Yahoo's `yinst`.  If `npm` was ever an
+acronym for anything, it was `node pm` or maybe `new pm`.
+
+So, in all seriousness, the "npm" project is named after its command-line
+utility, which was organically selected to be easily typed by a right-handed
+programmer using a US QWERTY keyboard layout, ending with the
+right-ring-finger in a postition to type the `-` key for flags and
+other command-line arguments.  That command-line utility is always
+lower-case, though it starts most sentences it is a part of.
+
+## How do I list installed packages?
+
+`npm ls`
+
+## How do I search for packages?
+
+`npm search`
+
+Arguments are greps.  `npm search jsdom` shows jsdom packages.
+
+## How do I update npm?
+
+    npm update npm -g
+
+You can also update all outdated local packages by doing `npm update` without
+any arguments, or global packages by doing `npm update -g`.
+
+Occasionally, the version of npm will progress such that the current
+version cannot be properly installed with the version that you have
+installed already.  (Consider, if there is ever a bug in the `update`
+command.)
+
+In those cases, you can do this:
+
+    curl https://npmjs.org/install.sh | sh
+
+## 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`.
+
+## What is a `module`?
+
+A module is anything that can be loaded with `require()` in a Node.js
+program.  The following things are all examples of things that can be
+loaded as modules:
+
+* A folder with a `package.json` file containing a `main` field.
+* A folder with an `index.js` file in it.
+* A JavaScript file.
+
+Most npm packages are modules, because they are libraries that you
+load with `require`.  However, there's no requirement that an npm
+package be a module!  Some only contain an executable command-line
+interface, and don't provide a `main` field for use in Node programs.
+
+Almost all npm packages (at least, those that are Node programs)
+*contain* many modules within them (because every file they load with
+`require()` is a module).
+
+In the context of a Node program, the `module` is also the thing that
+was loaded *from* a file.  For example, in the following program:
+
+    var req = require('request')
+
+we might say that "The variable `req` refers to the `request` module".
+
+## So, why is it the "`node_modules`" folder, but "`package.json`" file?  Why not `node_packages` or `module.json`?
+
+The `package.json` file defines the package.  (See "What is a
+package?" above.)
+
+The `node_modules` folder is the place Node.js looks for modules.
+(See "What is a module?" above.)
+
+For example, if you create a file at `node_modules/foo.js` and then
+had a program that did `var f = require('foo.js')` then it would load
+the module.  However, `foo.js` is not a "package" in this case,
+because it does not have a package.json.
+
+Alternatively, if you create a package which does not have an
+`index.js` or a `"main"` field in the `package.json` file, then it is
+not a module.  Even if it's installed in `node_modules`, it can't be
+an argument to `require()`.
+
+## `"node_modules"` is the name of my deity's arch-rival, and a Forbidden Word in my religion.  Can I configure npm to use a different folder?
+
+No.  This will never happen.  This question comes up sometimes,
+because it seems silly from the outside that npm couldn't just be
+configured to put stuff somewhere else, and then npm could load them
+from there.  It's an arbitrary spelling choice, right?  What's the big
+deal?
+
+At the time of this writing, the string `'node_modules'` appears 151
+times in 53 separate files in npm and node core (excluding tests and
+documentation).
+
+Some of these references are in node's built-in module loader.  Since
+npm is not involved **at all** at run-time, node itself would have to
+be configured to know where you've decided to stick stuff.  Complexity
+hurdle #1.  Since the Node module system is locked, this cannot be
+changed, and is enough to kill this request.  But I'll continue, in
+deference to your deity's delicate feelings regarding spelling.
+
+Many of the others are in dependencies that npm uses, which are not
+necessarily tightly coupled to npm (in the sense that they do not read
+npm's configuration files, etc.)  Each of these would have to be
+configured to take the name of the `node_modules` folder as a
+parameter.  Complexity hurdle #2.
+
+Furthermore, npm has the ability to "bundle" dependencies by adding
+the dep names to the `"bundledDependencies"` list in package.json,
+which causes the folder to be included in the package tarball.  What
+if the author of a module bundles its dependencies, and they use a
+different spelling for `node_modules`?  npm would have to rename the
+folder at publish time, and then be smart enough to unpack it using
+your locally configured name.  Complexity hurdle #3.
+
+Furthermore, what happens when you *change* this name?  Fine, it's
+easy enough the first time, just rename the `node_modules` folders to
+`./blergyblerp/` or whatever name you choose.  But what about when you
+change it again?  npm doesn't currently track any state about past
+configuration settings, so this would be rather difficult to do
+properly.  It would have to track every previous value for this
+config, and always accept any of them, or else yesterday's install may
+be broken tomorrow.  Complexity hurdle #5.
+
+Never going to happen.  The folder is named `node_modules`.  It is
+written indelibly in the Node Way, handed down from the ancient times
+of Node 0.3.
+
+## How do I install node with npm?
+
+You don't.  Try one of these node version managers:
+
+Unix:
+
+* <http://github.com/isaacs/nave>
+* <http://github.com/visionmedia/n>
+* <http://github.com/creationix/nvm>
+
+Windows:
+
+* <http://github.com/marcelklehr/nodist>
+* <https://github.com/hakobera/nvmw>
+
+## How can I use npm for development?
+
+See `npm-developers(7)` and `package.json(5)`.
+
+You'll most likely want to `npm link` your development folder.  That's
+awesomely handy.
+
+To set up your own private registry, check out `npm-registry(7)`.
+
+## Can I list a url as a dependency?
+
+Yes.  It should be a url to a gzipped tarball containing a single folder
+that has a package.json in its root, or a git url.
+(See "what is a package?" above.)
+
+## How do I symlink to a dev folder so I don't have to keep re-installing?
+
+See `npm-link(1)`
+
+## The package registry website.  What is that exactly?
+
+See `npm-registry(7)`.
+
+## I forgot my password, and can't publish.  How do I reset it?
+
+Go to <https://npmjs.org/forgot>.
+
+## I get ECONNREFUSED a lot.  What's up?
+
+Either the registry is down, or node's DNS isn't able to reach out.
+
+To check if the registry is down, open up <http://registry.npmjs.org/>
+in a web browser.  This will also tell you if you are just unable to
+access the internet for some reason.
+
+If the registry IS down, let me know by emailing <i@izs.me> or posting
+an issue at <https://github.com/isaacs/npm/issues>.  We'll have
+someone kick it or something.
+
+## Why no namespaces?
+
+Please see this discussion: <https://github.com/isaacs/npm/issues/798>
+
+tl;dr - It doesn't actually make things better, and can make them worse.
+
+If you want to namespace your own packages, you may: simply use the
+`-` character to separate the names.  npm is a mostly anarchic system.
+There is not sufficient need to impose namespace rules on everyone.
+
+## Who does npm?
+
+`npm view npm author`
+
+`npm view npm contributors`
+
+## I have a question or request not addressed here. Where should I put it?
+
+Post an issue on the github project:
+
+* <https://github.com/isaacs/npm/issues>
+
+## Why does npm hate me?
+
+npm is not capable of hatred.  It loves everyone, especially you.
+
+## SEE ALSO
+
+* npm(1)
+* npm-developers(7)
+* package.json(5)
+* npm-config(1)
+* npm-config(7)
+* npmrc(5)
+* npm-config(7)
+* npm-folders(5)
diff --git a/deps/npm/doc/misc/npm-index.md b/deps/npm/doc/misc/npm-index.md
new file mode 100644
index 000000000..e6eba281f
--- /dev/null
+++ b/deps/npm/doc/misc/npm-index.md
@@ -0,0 +1,403 @@
+npm-index(7) -- Index of all npm documentation
+==============================================
+
+## README(1)
+
+node package manager
+
+# Command Line Documentation
+
+## npm(1)
+
+node package manager
+
+## 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-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-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-prefix(1)
+
+Display prefix
+
+## npm-prune(1)
+
+Remove extraneous packages
+
+## npm-publish(1)
+
+Publish a package
+
+## npm-rebuild(1)
+
+Rebuild a package
+
+## npm-restart(1)
+
+Start 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-submodule(1)
+
+Add a package as a git submodule
+
+## npm-tag(1)
+
+Tag a published version
+
+## 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
+
+## npm(3)
+
+node package manager
+
+## npm-bin(3)
+
+Display npm bin folder
+
+## npm-bugs(3)
+
+Bugs for a package in a web browser maybe
+
+## 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-prefix(3)
+
+Display prefix
+
+## npm-prune(3)
+
+Remove extraneous packages
+
+## npm-publish(3)
+
+Publish a package
+
+## npm-rebuild(3)
+
+Rebuild a package
+
+## npm-restart(3)
+
+Start 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-submodule(3)
+
+Add a package as a git submodule
+
+## 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
+
+## 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
+
+## 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-faq(7)
+
+Frequently Asked Questions
+
+## npm-index(7)
+
+Index of all npm documentation
+
+## npm-registry(7)
+
+The JavaScript Package Registry
+
+## npm-scripts(7)
+
+How npm handles the "scripts" field
+
+## removing-npm(7)
+
+Cleaning the Slate
+
+## semver(7)
+
+The semantic versioner for npm
+
diff --git a/deps/npm/doc/misc/npm-registry.md b/deps/npm/doc/misc/npm-registry.md
new file mode 100644
index 000000000..0081984f7
--- /dev/null
+++ b/deps/npm/doc/misc/npm-registry.md
@@ -0,0 +1,94 @@
+npm-registry(7) -- The JavaScript Package Registry
+==================================================
+
+## DESCRIPTION
+
+To resolve packages by name and version, npm talks to a registry website
+that implements the CommonJS Package Registry specification for reading
+package info.
+
+Additionally, npm's package registry implementation supports several
+write APIs as well, to allow for publishing packages and managing user
+account information.
+
+The official public npm registry is at <http://registry.npmjs.org/>.  It
+is powered by a CouchDB database at
+<http://isaacs.iriscouch.com/registry>.  The code for the couchapp is
+available at <http://github.com/isaacs/npmjs.org>.  npm user accounts
+are CouchDB users, stored in the <http://isaacs.iriscouch.com/_users>
+database.
+
+The registry URL is supplied by the `registry` config parameter.  See
+`npm-config(1)`, `npmrc(5)`, and `npm-config(7)` for more on managing
+npm's configuration.
+
+## Can I run my own private registry?
+
+Yes!
+
+The easiest way is to replicate the couch database, and use the same (or
+similar) design doc to implement the APIs.
+
+If you set up continuous replication from the official CouchDB, and then
+set your internal CouchDB as the registry config, then you'll be able
+to read any published packages, in addition to your private ones, and by
+default will only publish internally.  If you then want to publish a
+package for the whole world to see, you can simply override the
+`--registry` config for that command.
+
+## I don't want my package published in the official registry. It's private.
+
+Set `"private": true` in your package.json to prevent it from being
+published at all, or
+`"publishConfig":{"registry":"http://my-internal-registry.local"}`
+to force it to be published only to your internal registry.
+
+See `package.json(5)` for more info on what goes in the package.json file.
+
+## Will you replicate from my registry into the public one?
+
+No.  If you want things to be public, then publish them into the public
+registry using npm.  What little security there is would be for nought
+otherwise.
+
+## Do I have to use couchdb to build a registry that npm can talk to?
+
+No, but it's way easier.
+
+## I published something elsewhere, and want to tell the npm registry about it.
+
+That is supported, but not using the npm client.  You'll have to get
+your hands dirty and do some HTTP.  The request looks something like
+this:
+
+    PUT /my-foreign-package
+    content-type:application/json
+    accept:application/json
+    authorization:Basic $base_64_encoded
+
+    { "name":"my-foreign-package"
+    , "maintainers":["owner","usernames"]
+    , "description":"A package that is hosted elsewhere"
+    , "keywords":["nih","my cheese smells the best"]
+    , "url":"http://my-different-registry.com/blerg/my-local-package"
+    }
+
+(Keywords and description are optional, but recommended.  Name,
+maintainers, and url are required.)
+
+Then, when a user tries to install "my-foreign-package", it'll redirect
+to your registry.  If that doesn't resolve to a valid package entry,
+then it'll fail, so please make sure that you understand the spec, and
+ask for help on the <npm-@googlegroups.com> mailing list.
+
+## Is there a website or something to see package docs and such?
+
+Yes, head over to <https://npmjs.org/>
+
+## SEE ALSO
+
+* npm-config(1)
+* npm-config(7)
+* npmrc(5)
+* npm-developers(7)
+* npm-disputes(7)
diff --git a/deps/npm/doc/misc/npm-scripts.md b/deps/npm/doc/misc/npm-scripts.md
new file mode 100644
index 000000000..b3f47699a
--- /dev/null
+++ b/deps/npm/doc/misc/npm-scripts.md
@@ -0,0 +1,245 @@
+npm-scripts(7) -- How npm handles the "scripts" field
+=====================================================
+
+## DESCRIPTION
+
+npm supports the "scripts" member of the package.json script, for the
+following scripts:
+
+* prepublish:
+  Run BEFORE the package is published.  (Also run on local `npm
+  install` without any arguments.)
+* publish, postpublish:
+  Run AFTER the package is published.
+* preinstall:
+  Run BEFORE the package is installed
+* install, postinstall:
+  Run AFTER the package is installed.
+* preuninstall, uninstall:
+  Run BEFORE the package is uninstalled.
+* postuninstall:
+  Run AFTER the package is uninstalled.
+* preupdate:
+  Run BEFORE the package is updated with the update command.
+* update, postupdate:
+  Run AFTER the package is updated with the update command.
+* pretest, test, posttest:
+  Run by the `npm test` command.
+* prestop, stop, poststop:
+  Run by the `npm stop` command.
+* prestart, start, poststart:
+  Run by the `npm start` command.
+* prerestart, restart, postrestart:
+  Run by the `npm restart` command. Note: `npm restart` will run the
+  stop and start scripts if no `restart` script is provided.
+
+Additionally, arbitrary scrips can be run by doing
+`npm run-script <stage> <pkg>`.
+
+## NOTE: INSTALL SCRIPTS ARE AN ANTIPATTERN
+
+**tl;dr** Don't use `install`.  Use a `.gyp` file for compilation, and
+`prepublish` for anything else.
+
+You should almost never have to explicitly set a `preinstall` or
+`install` script.  If you are doing this, please consider if there is
+another option.
+
+The only valid use of `install` or `preinstall` scripts is for
+compilation which must be done on the target architecture.  In early
+versions of node, this was often done using the `node-waf` scripts, or
+a standalone `Makefile`, and early versions of npm required that it be
+explicitly set in package.json.  This was not portable, and harder to
+do properly.
+
+In the current version of node, the standard way to do this is using a
+`.gyp` file.  If you have a file with a `.gyp` extension in the root
+of your package, then npm will run the appropriate `node-gyp` commands
+automatically at install time.  This is the only officially supported
+method for compiling binary addons, and does not require that you add
+anything to your package.json file.
+
+If you have to do other things before your package is used, in a way
+that is not dependent on the operating system or architecture of the
+target system, then use a `prepublish` script instead.  This includes
+tasks such as:
+
+* Compile CoffeeScript source code into JavaScript.
+* Create minified versions of JavaScript source code.
+* Fetching remote resources that your package will use.
+
+The advantage of doing these things at `prepublish` time instead of
+`preinstall` or `install` time is that they can be done once, in a
+single place, and thus greatly reduce complexity and variability.
+Additionally, this means that:
+
+* You can depend on `coffee-script` as a `devDependency`, and thus
+  your users don't need to have it installed.
+* You don't need to include the minifiers in your package, reducing
+  the size for your users.
+* You don't need to rely on your users having `curl` or `wget` or
+  other system tools on the target machines.
+
+## DEFAULT VALUES
+
+npm will default some script values based on package contents.
+
+* `"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`.
+
+* `"preinstall": "node-waf clean || true; node-waf configure build"`:
+
+  If there is a `wscript` file in the root of your package, npm will
+  default the `preinstall` command to compile using node-waf.
+
+## USER
+
+If npm was invoked with root privileges, then it will change the uid
+to the user account or uid specified by the `user` config, which
+defaults to `nobody`.  Set the `unsafe-perm` flag to run scripts with
+root privileges.
+
+## ENVIRONMENT
+
+Package scripts run in an environment where many pieces of information
+are made available regarding the setup of npm and the current state of
+the process.
+
+
+### path
+
+If you depend on modules that define executable scripts, like test
+suites, then those executables will be added to the `PATH` for
+executing the scripts.  So, if your package.json has this:
+
+    { "name" : "foo"
+    , "dependencies" : { "bar" : "0.1.x" }
+    , "scripts": { "start" : "bar ./test" } }
+
+then you could run `npm start` to execute the `bar` script, which is
+exported into the `node_modules/.bin` directory on `npm install`.
+
+### package.json vars
+
+The package.json fields are tacked onto the `npm_package_` prefix. So,
+for instance, if you had `{"name":"foo", "version":"1.2.5"}` in your
+package.json file, then your package scripts would have the
+`npm_package_name` environment variable set to "foo", and the
+`npm_package_version` set to "1.2.5"
+
+### configuration
+
+Configuration parameters are put in the environment with the
+`npm_config_` prefix. For instance, you can view the effective `root`
+config by checking the `npm_config_root` environment variable.
+
+### Special: package.json "config" hash
+
+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
+
+### current lifecycle event
+
+Lastly, the `npm_lifecycle_event` environment variable is set to
+whichever stage of the cycle is being executed. So, you could have a
+single script used for different parts of the process which switches
+based on what's currently happening.
+
+Objects are flattened following this format, so if you had
+`{"scripts":{"install":"foo.js"}}` in your package.json, then you'd
+see this in the script:
+
+    process.env.npm_package_scripts_install === "foo.js"
+
+## EXAMPLES
+
+For example, if your package.json contains this:
+
+    { "scripts" :
+      { "install" : "scripts/install.js"
+      , "postinstall" : "scripts/install.js"
+      , "uninstall" : "scripts/uninstall.js"
+      }
+    }
+
+then the `scripts/install.js` will be called for the install,
+post-install, stages of the lifecycle, and the `scripts/uninstall.js`
+would be called when the package is uninstalled.  Since
+`scripts/install.js` is running for three different phases, it would
+be wise in this case to look at the `npm_lifecycle_event` environment
+variable.
+
+If you want to run a make command, you can do so.  This works just
+fine:
+
+    { "scripts" :
+      { "preinstall" : "./configure"
+      , "install" : "make && make install"
+      , "test" : "make test"
+      }
+    }
+
+## EXITING
+
+Scripts are run by passing the line as a script argument to `sh`.
+
+If the script exits with a code other than 0, then this will abort the
+process.
+
+Note that these script files don't have to be nodejs or even
+javascript programs. They just have to be some kind of executable
+file.
+
+## HOOK SCRIPTS
+
+If you want to run a specific script at a specific lifecycle event for
+ALL packages, then you can use a hook script.
+
+Place an executable file at `node_modules/.hooks/{eventname}`, and
+it'll get run for all packages when they are going through that point
+in the package lifecycle for any packages installed in that root.
+
+Hook scripts are run exactly the same way as package.json scripts.
+That is, they are in a separate child process, with the env described
+above.
+
+## BEST PRACTICES
+
+* Don't exit with a non-zero error code unless you *really* mean it.
+  Except for uninstall scripts, this will cause the npm action to
+  fail, and potentially be rolled back.  If the failure is minor or
+  only will prevent some optional features, then it's better to just
+  print a warning and exit successfully.
+* Try not to use scripts to do what npm can do for you.  Read through
+  `package.json(5)` to see all the things that you can specify and enable
+  by simply describing your package appropriately.  In general, this
+  will lead to a more robust and consistent state.
+* Inspect the env to determine where to put things.  For instance, if
+  the `npm_config_binroot` environ is set to `/home/user/bin`, then
+  don't try to install executables into `/usr/local/bin`.  The user
+  probably set it up that way for a reason.
+* Don't prefix your script commands with "sudo".  If root permissions
+  are required for some reason, then it'll fail with that error, and
+  the user will sudo the npm command in question.
+
+## SEE ALSO
+
+* npm-run-script(1)
+* package.json(5)
+* npm-developers(7)
+* npm-install(1)
diff --git a/deps/npm/doc/misc/removing-npm.md b/deps/npm/doc/misc/removing-npm.md
new file mode 100644
index 000000000..bedd28a2f
--- /dev/null
+++ b/deps/npm/doc/misc/removing-npm.md
@@ -0,0 +1,54 @@
+npm-removal(1) -- Cleaning the Slate
+====================================
+
+## SYNOPSIS
+
+So sad to see you go.
+
+    sudo npm uninstall npm -g
+
+Or, if that fails, get the npm source code, and do:
+
+    sudo make uninstall
+
+## More Severe Uninstalling
+
+Usually, the above instructions are sufficient.  That will remove
+npm, but leave behind anything you've installed.
+
+If that doesn't work, or if you require more drastic measures,
+continue reading.
+
+Note that this is only necessary for globally-installed packages.  Local
+installs are completely contained within a project's `node_modules`
+folder.  Delete that folder, and everything is gone (unless a package's
+install script is particularly ill-behaved).
+
+This assumes that you installed node and npm in the default place.  If
+you configured node with a different `--prefix`, or installed npm with a
+different prefix setting, then adjust the paths accordingly, replacing
+`/usr/local` with your install prefix.
+
+To remove everything npm-related manually:
+
+    rm -rf /usr/local/{lib/node{,/.npm,_modules},bin,share/man}/npm*
+
+If you installed things *with* npm, then your best bet is to uninstall
+them with npm first, and then install them again once you have a
+proper install.  This can help find any symlinks that are lying
+around:
+
+    ls -laF /usr/local/{lib/node{,/.npm},bin,share/man} | grep npm
+
+Prior to version 0.3, npm used shim files for executables and node
+modules.  To track those down, you can do the following:
+
+    find /usr/local/{lib/node,bin} -exec grep -l npm \{\} \; ;
+
+(This is also in the README file.)
+
+## SEE ALSO
+
+* README
+* npm-rm(1)
+* npm-prune(1)
diff --git a/deps/npm/doc/misc/semver.md b/deps/npm/doc/misc/semver.md
new file mode 100644
index 000000000..b8e193948
--- /dev/null
+++ b/deps/npm/doc/misc/semver.md
@@ -0,0 +1,111 @@
+semver(7) -- The semantic versioner for npm
+===========================================
+
+## Usage
+
+    $ npm install semver
+
+    semver.valid('1.2.3') // '1.2.3'
+    semver.valid('a.b.c') // null
+    semver.clean('  =v1.2.3   ') // '1.2.3'
+    semver.satisfies('1.2.3', '1.x || >=2.5.0 || 5.0.0 - 7.2.3') // true
+    semver.gt('1.2.3', '9.8.7') // false
+    semver.lt('1.2.3', '9.8.7') // true
+
+As a command-line utility:
+
+    $ semver -h
+
+    Usage: semver <version> [<version> [...]] [-r <range> | -i <inc> | -d <dec>]
+    Test if version(s) satisfy the supplied range(s), and sort them.
+
+    Multiple versions or ranges may be supplied, unless increment
+    or decrement options are specified.  In that case, only a single
+    version may be used, and it is incremented by the specified level
+
+    Program exits successfully if any valid version satisfies
+    all supplied ranges, and prints all satisfying versions.
+
+    If no versions are valid, or ranges are not satisfied,
+    then exits failure.
+
+    Versions are printed in ascending order, so supplying
+    multiple versions to the utility will just sort them.
+
+## Versions
+
+A "version" is described by the v2.0.0 specification found at
+<http://semver.org/>.
+
+A leading `"="` or `"v"` character is stripped off and ignored.
+
+## Ranges
+
+The following range styles are supported:
+
+* `1.2.3` A specific version.  When nothing else will do.  Note that
+  build metadata is still ignored, so `1.2.3+build2012` will satisfy
+  this range.
+* `>1.2.3` Greater than a specific version.
+* `<1.2.3` Less than a specific version.  If there is no prerelease
+  tag on the version range, then no prerelease version will be allowed
+  either, even though these are technically "less than".
+* `>=1.2.3` Greater than or equal to.  Note that prerelease versions
+  are NOT equal to their "normal" equivalents, so `1.2.3-beta` will
+  not satisfy this range, but `2.3.0-beta` will.
+* `<=1.2.3` Less than or equal to.  In this case, prerelease versions
+  ARE allowed, so `1.2.3-beta` would satisfy.
+* `1.2.3 - 2.3.4` := `>=1.2.3 <=2.3.4`
+* `~1.2.3` := `>=1.2.3-0 <1.3.0-0`  "Reasonably close to 1.2.3".  When
+  using tilde operators, prerelease versions are supported as well,
+  but a prerelease of the next significant digit will NOT be
+  satisfactory, so `1.3.0-beta` will not satisfy `~1.2.3`.
+* `~1.2` := `>=1.2.0-0 <1.3.0-0` "Any version starting with 1.2"
+* `1.2.x` := `>=1.2.0-0 <1.3.0-0` "Any version starting with 1.2"
+* `~1` := `>=1.0.0-0 <2.0.0-0` "Any version starting with 1"
+* `1.x` := `>=1.0.0-0 <2.0.0-0` "Any version starting with 1"
+
+
+Ranges can be joined with either a space (which implies "and") or a
+`||` (which implies "or").
+
+## Functions
+
+All methods and classes take a final `loose` boolean argument that, if
+true, will be more forgiving about not-quite-valid semver strings.
+The resulting output will always be 100% strict, of course.
+
+Strict-mode Comparators and Ranges will be strict about the SemVer
+strings that they parse.
+
+* valid(v): Return the parsed version, or null if it's not valid.
+* inc(v, release): Return the version incremented by the release type
+  (major, minor, patch, or prerelease), or null if it's not valid.
+
+### Comparison
+
+* gt(v1, v2): `v1 > v2`
+* gte(v1, v2): `v1 >= v2`
+* lt(v1, v2): `v1 < v2`
+* lte(v1, v2): `v1 <= v2`
+* eq(v1, v2): `v1 == v2` This is true if they're logically equivalent,
+  even if they're not the exact same string.  You already know how to
+  compare strings.
+* neq(v1, v2): `v1 != v2` The opposite of eq.
+* cmp(v1, comparator, v2): Pass in a comparison string, and it'll call
+  the corresponding function above.  `"==="` and `"!=="` do simple
+  string comparison, but are included for completeness.  Throws if an
+  invalid comparison string is provided.
+* compare(v1, v2): Return 0 if v1 == v2, or 1 if v1 is greater, or -1 if
+  v2 is greater.  Sorts in ascending order if passed to Array.sort().
+* rcompare(v1, v2): The reverse of compare.  Sorts an array of versions
+  in descending order when passed to Array.sort().
+
+
+### Ranges
+
+* validRange(range): Return the valid range or null if it's not valid
+* satisfies(version, range): Return true if the version satisfies the
+  range.
+* maxSatisfying(versions, range): Return the highest version in the list
+  that satisfies the range, or null if none of them do.