deps: upgrade npm to 4.0.5

PR-URL: https://github.com/nodejs/node/pull/10330
Reviewed-By: Myles Borins <myles.borins@gmail.com>

1 files changed, 104 insertions, 73 deletions

diff --git a/deps/npm/doc/misc/npm-disputes.md b/deps/npm/doc/misc/npm-disputes.md
index 9fb1eaab45..47644888d9 100644
--- a/deps/npm/doc/misc/npm-disputes.md
+++ b/deps/npm/doc/misc/npm-disputes.md
@@ -1,7 +1,16 @@
 npm-disputes(7) -- Handling Module Name Disputes
 ================================================
 
-## SYNOPSIS
+This document describes the steps that you should take to resolve module name
+disputes with other npm publishers. It also describes special steps you should
+take about names you think infringe your trademarks.
+
+This document is a clarification of the acceptable behavior outlined in the
+[npm Code of Conduct](https://www.npmjs.com/policies/conduct), and nothing in
+this document should be interpreted to contradict any aspect of the npm Code of
+Conduct.
+
+## TL;DR
 
 1. Get the author email with `npm owner ls <pkgname>`
 2. Email the author, CC <support@npmjs.com>
@@ -11,87 +20,109 @@ Don't squat on package names.  Publish code or move out of the way.
 
 ## DESCRIPTION
 
-There sometimes arise cases where a user publishes a module, and then
-later, some other user wants to use that name.  Here are some common
-ways that happens (each of these is based on actual events.)
-
-1. Joe writes a JavaScript module `foo`, which is not node-specific.
-   Joe doesn't use node at all.  Bob   wants to use `foo` in node, so he
-   wraps it in an npm module.  Some time later, Joe starts using node,
-   and wants to take over management of his program.
-2. Bob writes an npm module `foo`, and publishes it.  Perhaps much
-   later, Joe finds a bug in `foo`, and fixes it.  He sends a pull
-   request to Bob, but Bob doesn't have the time to deal with it,
-   because he has a new job and a new baby and is focused on his new
-   erlang project, and kind of not involved with node any more.  Joe
-   would like to publish a new `foo`, but can't, because the name is
-   taken.
-3. Bob writes a 10-line flow-control library, and calls it `foo`, and
-   publishes it to the npm registry.  Being a simple little thing, it
-   never really has to be updated.  Joe works for Foo Inc, the makers
-   of the critically acclaimed and widely-marketed `foo` JavaScript
-   toolkit framework.  They publish it to npm as `foojs`, but people are
-   routinely confused when `npm install foo` is some different thing.
-4. Bob writes a parser for the widely-known `foo` file format, because
-   he needs it for work.  Then, he gets a new job, and never updates the
-   prototype.  Later on, Joe writes a much more complete `foo` parser,
-   but can't publish, because Bob's `foo` is in the way.
-
-The validity of Joe's claim in each situation can be debated.  However,
-Joe's appropriate course of action in each case is the same.
-
-1. `npm owner ls foo`.  This will tell Joe the email address of the
-   owner (Bob).
-2. Joe emails Bob, explaining the situation **as respectfully as
-   possible**, and what he would like to do with the module name.  He
-   adds the npm support staff <support@npmjs.com> to the CC list of
-   the email.  Mention in the email that Bob can run `npm owner add
-   joe foo` to add Joe as an owner of the `foo` package.
-3. After a reasonable amount of time, if Bob has not responded, or if
-   Bob and Joe can't come to any sort of resolution, email support
-   <support@npmjs.com> and we'll sort it out.  ("Reasonable" is
-   usually at least 4 weeks, but extra time is allowed around common
-   holidays.)
+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. Alice writes a JavaScript module `foo`, which is not node-specific. Alice
+   doesn't use node at all. Yusuf wants to use `foo` in node, so he wraps it in
+   an npm module. Some time later, Alice starts using node, and wants to take
+   over management of her program.
+2. Yusuf writes an npm module `foo`, and publishes it. Perhaps much later, Alice
+   finds a bug in `foo`, and fixes it. She sends a pull request to Yusuf, but
+   Yusuf 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. Alice would like to publish a new `foo`, but can't,
+   because the name is taken.
+3. Yusuf 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. Alice 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. Yusuf 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, Alice writes a much more complete `foo` parser, but can't publish,
+   because Yusuf's `foo` is in the way.
+
+1. `npm owner ls foo`. This will tell Alice the email address of the owner
+   (Yusuf).
+2. Alice emails Yusuf, explaining the situation **as respectfully as possible**,
+   and what she would like to do with the module name. She adds the npm support
+   staff <support@npmjs.com> to the CC list of the email. Mention in the email
+   that Yusuf can run npm owner `add alice foo` to add Alice as an owner of the
+   foo package.
+3. After a reasonable amount of time, if Yusuf has not responded, or if Yusuf
+   and Alice can't come to any sort of resolution, email support
+   <support@npmjs.com> and we'll sort it out. ("Reasonable" is usually at least
+   4 weeks.)
 
 ## 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.
+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.
+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:
+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).
+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.
+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.
+7. Other things forbidden by the npm
+   [Code of Conduct](https://www.npmjs.com/policies/conduct) such as hateful
+   language, pornographic content, or harassment.
+
+If you see bad behavior like this, please report it to <abuse@npmjs.com> right
+away. **You are never expected to resolve abusive behavior on your own. We are
+here to help.**
+
+## TRADEMARKS
+
+If you think another npm publisher is infringing your trademark, such as by
+using a confusingly similar package name, email <abuse@npmjs.com> with a link to
+the package or user account on [https://npmjs.com](https://npmjs.com). Attach a
+copy of your trademark registration certificate.
+
+If we see that the package's publisher is intentionally misleading others by
+misusing your registered mark without permission, we will transfer the package
+name to you. Otherwise, we will contact the package publisher and ask them to
+clear up any confusion with changes to their package's `README` file or
+metadata.
+
+## CHANGES
+
+This is a living document and may be updated from time to time. Please refer to
+the [git history for this document](https://github.com/npm/npm/commits/master/doc/misc/npm-disputes.md)
+to view the changes.
+
+## LICENSE
+
+Copyright (C) npm, Inc., All rights reserved
+
+This document may be reused under a Creative Commons Attribution-ShareAlike
+License.
 
 ## SEE ALSO