See also: #3059, #8402, #9722, #9733, probably many others.

Many, many people intensely dislike the fact that a lifecycle event named "prepublish" also gets run when a package is also installed for development, as this precludes the ability to have a set of validation checks that get run before publishing (and also because the name becomes confusingly inaccurate). The reasons for this behavior have been discussed, bikeshedded, and vehemently argued over elsewhere. There is a consensus that the current behavior is undesirable, and the CLI team agrees that this situation needs to be fixed. This is what we intend to do:

1. Introduce a new prepare lifecycle event, which has the current behavior of the prepublish event – it runs before the package tarball is packed and uploaded to the registry during the publishing process, as well as when you run npm install (with no package name) after cloning a package, to prepare it for use (i.e. by transpiling source).
2. Introduce a new prepublishOnly lifecycle event, which runs only at prepublish time.
3. Add a new warning when the prepublish hook is used that the current behavior is deprecated, and will be removed at some point in the future.
4. In a year or so, make a semver-major bump to npm and make prepublish's behavior match prepublishOnly.
5. Either then or sometime after that, deprecate prepublishOnly and have just prepare and prepublish.

This should allow everyone to get the behavior they want, and will (eventually) result in a solution that is intuitive and unsurprising to everyone, and allows us to do so in about as gentle a way as possible for something so potentially disruptive.

Thoughts? Things we haven't considered? Parts 1-3 can (and will) be implemented as part of npm@3, probably over the next couple months, so it would be nice to get people's feedback relatively quickly.