deps: upgrade npm to 2.9.1

Reviewed-By: Julien Gilli <julien.gilli@joyent.com>
PR-URL: nodejs/node-v0.x-archive#25289

deps/npm/AUTHORS

@@ -271,3 +271,6 @@ Michiel Sikma <michiel@wedemandhtml.com>
 Jakob Krigovsky <jakob.krigovsky@gmail.com>
 Charmander <~@charmander.me>
 erik wienhold <git@ewie.name>
+James Butler <james.butler@sandfox.co.uk>
+Kevin Kragenbrink <kevin@gaikai.com>
+Arnaud Rinquin <rinquin.arnaud@gmail.com>

deps/npm/CHANGELOG.md

@@ -1,3 +1,149 @@
+### v2.9.1 (2015-04-30):
+
+#### WOW! MORE GIT FIXES! YOU LOVE THOSE!
+
+The first item below is actually a pretty big deal, as it fixes (with a
+one-word change and a much, much longer test case (thanks again,
+[@iarna](https://github.com/iarna))) a regression that's been around for months
+now. If you're depending on multiple branches of a single git dependency in a
+single project, you probably want to check out `npm@2.9.1` and verify that
+things (again?) work correctly in your project.
+
+* [`178a6ad`](https://github.com/npm/npm/commit/178a6ad540215820d16217465a5f220d8c95a313)
+  [#7202](https://github.com/npm/npm/issues/7202) When caching git
+  dependencies, do so by the whole URL, including the branch name, so that if a
+  single application depends on multiple branches from the same repository (in
+  practice, multiple version tags), every install is of the correct version,
+  instead of reusing whichever branch the caching process happened to check out
+  first.  ([@iarna](https://github.com/iarna))
+* [`63b79cc`](https://github.com/npm/npm/commit/63b79ccde092a9cb3b1f34abe43e1d2ba69c0dbf)
+  [#8084](https://github.com/npm/npm/issues/8084) Ensure that Bitbucket,
+  GitHub, and Gitlab dependencies are installed the same way as non-hosted git
+  dependencies, fixing `npm install --link`.
+  ([@laiso](https://github.com/laiso))
+
+#### DOCUMENTATION FIXES AND TWEAKS
+
+These changes may seem simple and small (except Lin's fix to the package name
+restrictions, which was more an egregious oversight on our part), but cleaner
+documentation makes npm significantly more pleasant to use. I really appreciate
+all the typo fixes, clarifications, and formatting tweaks people send us, and
+am delighted that we get so many of these pull requests. Thanks, everybody!
+
+* [`ca478dc`](https://github.com/npm/npm/commit/ca478dcaa29b8f07cd6fe515a3c4518166819291)
+  [#8137](https://github.com/npm/npm/issues/8137) Somehow, we had failed to
+  clearly document the full restrictions on package names.
+  [@linclark](https://github.com/linclark) has now fixed that, although we will
+  take with us to our graves the reasons why the maximum package name length is 214
+  characters (well, OK, it was that that was the longest name in the registry
+  when we decided to put a cap on the name length).
+  ([@linclark](https://github.com/linclark))
+* [`b574076`](https://github.com/npm/npm/commit/b5740767c320c1eff3576a8d63952534a0fbb936)
+  [#8079](https://github.com/npm/npm/issues/8079) Make the `npm shrinkwrap`
+  documentation use code formatting for examples consistently. It would be
+  great to do this for more commands HINT HINT.
+  ([@RichardLitt](https://github.com/RichardLitt))
+* [`1ff636e`](https://github.com/npm/npm/commit/1ff636e2db3852a53e38c866fed7eafdacd307fc)
+  [#8105](https://github.com/npm/npm/issues/8105) Document that the global
+  `npmrc` goes in `$PREFIX/etc/npmrc`, instead of `$PREFIX/npmrc`.
+  ([@anttti](https://github.com/anttti))
+* [`c3f2f7c`](https://github.com/npm/npm/commit/c3f2f7c299342e1c1eccc55a976a63c607f51621)
+  [#8127](https://github.com/npm/npm/issues/8127) Document how to use `npm run
+  build` directly (hint: it's different from `npm build`!).
+  ([@mikemaccana](https://github.com/mikemaccana))
+* [`873e467`](https://github.com/npm/npm/commit/873e46757e1986761b15353f94580a071adcb383)
+  [#8069](https://github.com/npm/npm/issues/8069) Take the old, dead npm
+  mailing list address out of `package.json`. It seems that people don't have
+  much trouble figuring out how to report errors to npm.
+  ([@robertkowalski](https://github.com/robertkowalski))
+
+#### ENROBUSTIFICATIONMENT
+
+* [`5abfc9c`](https://github.com/npm/npm/commit/5abfc9c9017da714e47a3aece750836b4f9af6a9)
+  [#7973](https://github.com/npm/npm/issues/7973) `npm run-script` completion
+  will only suggest run scripts, instead of including dependencies. If for some
+  reason you still wanted it to suggest dependencies, let us know.
+  ([@mantoni](https://github.com/mantoni))
+* [`4b564f0`](https://github.com/npm/npm/commit/4b564f0ce979dc74c09604f4d46fd25a2ee63804)
+  [#8081](https://github.com/npm/npm/issues/8081) Use `osenv` to parse the
+  environment's `PATH` in a platform-neutral way.
+  ([@watilde](https://github.com/watilde))
+* [`a4b6238`](https://github.com/npm/npm/commit/a4b62387b41848818973eeed056fd5c6570274f3)
+  [#8094](https://github.com/npm/npm/issues/8094) When we refactored the
+  configuration code to split out checking for IPv4 local addresses, we
+  inadvertently completely broke it by failing to return the values. In
+  addition, just the call to `os.getInterfaces()` could throw on systems where
+  querying the network configuration requires elevated privileges (e.g. Amazon
+  Lambda). Add the return, and trap errors so they don't cause npm to explode.
+  Thanks to [@mhart](https://github.com/mhart) for bringing this to our
+  attention! ([@othiym23](https://github.com/othiym23))
+
+#### DEPENDENCY UPDATES WAIT FOR NO SOPHONT
+
+* [`000cd8b`](https://github.com/npm/npm/commit/000cd8b52104942ac3404f0ad0651d82f573da37)
+  `rimraf@2.3.3`: More informative assertions on argument validation failure.
+  ([@isaacs](https://github.com/isaacs))
+* [`530a2e3`](https://github.com/npm/npm/commit/530a2e369128270f3e098f0e9be061533003b0eb)
+  `lru-cache@2.6.2`: Revert to old key access-time behavior, as it was correct
+  all along. ([@isaacs](https://github.com/isaacs))
+* [`d88958c`](https://github.com/npm/npm/commit/d88958ca02ce81b027b9919aec539d0145875a59)
+  `minimatch@2.0.7`: Feature detection and test improvements.
+  ([@isaacs](https://github.com/isaacs))
+* [`3fa39e4`](https://github.com/npm/npm/commit/3fa39e4d492609d5d045033896dcd99f7b875329)
+  `nock@1.7.1` ([@pgte](https://github.com/pgte))
+
+### v2.9.0 (2015-04-23):
+
+This week was kind of a breather to concentrate on fixing up the tests on the
+`multi-stage` branch, and not mess with git issues for a little while.
+Unfortunately, There are now enough severe git issues that we'll probably have
+to spend another couple weeks tackling them. In the meantime, enjoy these two
+small features. They're just enough to qualify for a semver-minor bump:
+
+#### NANOFEATURES
+
+* [`2799322`](https://github.com/npm/npm/commit/279932298ce5b589c5eea9439ac40b88b99c6a4a)
+  [#7426](https://github.com/npm/npm/issues/7426) Include local modules in `npm
+  outdated` and `npm update`.  ([@ArnaudRinquin](https://github.com/ArnaudRinquin))
+* [`2114862`](https://github.com/npm/npm/commit/21148620fa03a582f4ec436bb16bd472664f2737)
+  [#8014](https://github.com/npm/npm/issues/8014) The prefix used before the
+  version on version tags is now configurable via `tag-version-prefix`. Be
+  careful with this one and read the docs before using it.
+  ([@kkragenbrink](https://github.com/kkragenbrink))
+
+#### OTHER MINOR TWEAKS
+
+* [`18ce0ec`](https://github.com/npm/npm/commit/18ce0ecd2d94ad3af01e997f1396515892dd363c)
+  [#3032](https://github.com/npm/npm/issues/3032) `npm unpublish` will now use
+  the registry set in `package.json`, just like `npm publish`. This only
+  applies, for now, when unpublishing the entire package, as unpublishing a
+  single version requires the name be included on the command line and
+  therefore doesn't read from `package.json`. ([@watilde](https://github.com/watilde))
+* [`9ad2100`](https://github.com/npm/npm/commit/9ad210042242e51d52b2a8b633d8e59248f5faa4)
+  [#8008](https://github.com/npm/npm/issues/8008) Once again, when considering
+  what to install on `npm install`, include `devDependencies`.
+  ([@smikes](https://github.com/smikes))
+* [`5466260`](https://github.com/npm/npm/commit/546626059909dca1906454e820ca4e315c1795bd)
+  [#8003](https://github.com/npm/npm/issues/8003) Clarify the documentation
+  around scopes to make it easier to understand how they support private
+  packages. ([@smikes](https://github.com/smikes))
+
+#### DEPENDENCIES WILL NOT STOP UNTIL YOU ARE VERY SLEEPY
+
+* [`faf65a7`](https://github.com/npm/npm/commit/faf65a7bbb2fad13216f64ed8f1243bafe743f97)
+  `init-package-json@1.4.2`: If there are multiple validation errors and
+  warnings, ensure they all get displayed (includes a rad new way of testing
+  `init-package-json` contributed by
+  [@michaelnisi](https://github.com/michaelnisi)).
+  ([@MisumiRize](https://github.com/MisumiRize))
+* [`7f10f38`](https://github.com/npm/npm/commit/7f10f38d29a8423d7cde8103fa7b64ac728da1e0)
+  `editor@1.0.0`: `1.0.0` is literally more than `0.1.0` (no change aside from
+  version number). ([@substack](https://github.com/substack))
+* [`4979af3`](https://github.com/npm/npm/commit/4979af3fcae5a3962383b7fdad3162381e62eefe)
+  [#6805](https://github.com/npm/npm/issues/6805) `npm-registry-client@6.3.3`:
+  Decode scoped package names sent by the registry so they look nicer.
+  ([@mmalecki](https://github.com/mmalecki))
+
 ### v2.8.4 (2015-04-16):
 
 This is the fourth release of npm this week, so it's mostly just landing a few

deps/npm/Makefile

@@ -235,7 +235,7 @@ authors:
 	git add AUTHORS &&\
 	git commit -m "update AUTHORS" || true
 
-publish: link doc authors
+publish: authors link doc
 	@git push origin :v$(shell npm -v) 2>&1 || true
 	git clean -fd &&\
 	git push origin $(BRANCH) &&\

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

@@ -12,7 +12,10 @@ npm-build(1) -- Build a package
 
 This is the plumbing command called by `npm link` and `npm install`.
 
-It should generally not be called directly.
+It should generally be called during installation, but if you need to run it
+directly, run:
+
+    npm run-script build
 
 ## SEE ALSO
 

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

@@ -9,10 +9,10 @@ npm-shrinkwrap(1) -- Lock down dependency versions
 
 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".
+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
+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
@@ -53,13 +53,13 @@ and package C:
     }
 
 If these are the only versions of A, B, and C available in the
-registry, then a normal "npm install A" will install:
+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
+However, if B@0.0.2 is published, then a fresh `npm install A` will
 install:
 
     A@0.1.0
@@ -96,7 +96,7 @@ This generates npm-shrinkwrap.json, which will look something like this:
     }
 
 The shrinkwrap command has locked down the dependencies based on
-what's currently installed in node_modules.  When "npm install"
+what's currently installed in node_modules.  When `npm install`
 installs a package with a npm-shrinkwrap.json file in the package
 root, the shrinkwrap file (rather than package.json files) completely
 drives the installation of that package and all of its dependencies
@@ -109,31 +109,31 @@ 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.
+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
+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
+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
+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
+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
+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
@@ -142,13 +142,13 @@ 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
+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
+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

deps/npm/doc/files/npmrc.md

@@ -17,7 +17,7 @@ The four relevant files are:
 
 * per-project config file (/path/to/my/project/.npmrc)
 * per-user config file (~/.npmrc)
-* global config file ($PREFIX/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`

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

@@ -17,14 +17,23 @@ 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 tips:
+The name is what your thing is called.
 
+Some rules:
+
+* The name must be shorter than 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 ends up being part of a URL, an argument on the command line, and a
-  folder name. Any name with non-url-safe characters will be rejected.
-  Also, it can't start with a dot or an underscore.
 * 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

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

@@ -804,6 +804,19 @@ 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"

deps/npm/doc/misc/npm-scope.md

@@ -13,9 +13,9 @@ followed by a slash, e.g.
 Scopes are a way of grouping related packages together, and also affect a few
 things about the way npm treats the package.
 
-**As of 2014-09-03, scoped packages are not supported by the public npm registry**.
-However, the npm client is backwards-compatible with un-scoped registries, so
-it can be used to work with scoped and un-scoped registries at the same time.
+Scoped packages are supported by the public npm registry.  The npm
+client is backwards-compatible with un-scoped registries, so it can be
+used to work with scoped and un-scoped registries at the same time.
 
 ## Installing scoped packages
 
@@ -51,10 +51,29 @@ just specifying to require the module `mypackage` in the folder called `@myorg`.
 
 ## Publishing scoped packages
 
-Scoped packages can be published to any registry that supports them.
-*As of 2014-09-03, the public npm registry does not support scoped packages*,
-so attempting to publish a scoped package to the registry will fail unless
-you have associated that scope with a different registry, see below.
+Scoped packages can be published to any registry that supports them, including
+the public npm registry.
+
+(As of 2015-04-19, the public npm registry **does** support scoped packages)
+
+If you wish, you may associate a scope with a registry; see below.
+
+### Publishing public scoped packages to the public npm registry
+
+To publish a public scoped package, you must specify `--access public` with
+the initial publication.  This will publish the package and set access
+to `public` as if you had run `npm access public` after publishing.
+
+### Publishing private scoped packages to the npm registry
+
+To publish a private scoped package to the npm registry, you must have
+an [npm Private Modules](https://www.npmjs.com/private-modules)
+account.
+
+You can then publish the module with `npm publish` or `npm publish
+--access restricted`, and it will be present in the npm registry, with
+restricted access.  You can then change the access permissions, if
+desired, with `npm access` or on the npmjs.com website.
 
 ## Associating a scope with a registry
 
@@ -81,4 +100,5 @@ that registry instead.
 ## SEE ALSO
 
 * npm-install(1)
-* npm-publish(1)
+* npm-publish(1)
+* npm-access(1)