👍 awesome, this is great

\o/ niiiiiice

+1 that is really good

+1 great!

👍 keen

Awesome, thanks!!

Sounds great! The new prepare hook will be useful as well.

👍 💯 😄

🎉

@othiym23 I imagine #8263 will be tackled separately from this?

There is a god! 🙏

Yes absolutely yes!

👍 Thanks for tackling this issue!

Brilliant 👍

@othiym23 is there any chance that a tiny 1.x and 2.x patch could be put out, that detects the "prepublishOnly" and "prepare" scripts, and warns that the user should be using npm 3.something to get proper publish behavior? I know modifying 1.x is probably unlikely, but it would be very useful in helping encourage people to update to npm 3, and also ensuring they don't unknowingly miss a critical "before publish" step.

If not, then my only option would be to use in-publish inside "prepublish" for now - but then once "prepublish" does the right thing when your step 4 happens, I'd have to keep in-publish in there forever to ensure that 1.x, 2.x, and too-early-3.x users don't accidentally miss a publish step.

I kind of feel like prepublish should just be decommissioned and never replaced, rather than changing the semantics such that old npm running on an updated module does something surprising.

Steps 1, 2, and 3 seem wonderful to me - it's just steps 4 and 5 I'm concerned about. Instead, if they were a single step 4: In a year or so, make a semver-major bump to npm and remove prepublish, and have just "prepare" and "prepublishOnly". The name will be unfortunate, but I think, less bad than having now-era "prepublish" scripts conflict semantically with future-era "prepublish" scripts.

is there any chance that a tiny 1.x

No. The book is closed on npm@1. There is going to be one more release of it that warns people to upgrade to at least npm@2 and that early errors when users try to install scoped packages, strictly so that we can transition to npm@2 in Node 0.10 LTS.

and 2.x

Probably, although we'd be more likely to cherry-pick 1-3 onto the 2.x branch, or add a simple deprecation warning to uses of prepublish that its behavior is changing. That's an LTS discussion, and so will probably involve @zkat and the Node LTS working group.

The reason to wait a year between steps 3 and 4 is twofold - to give developers a chance to migrate to prepare and prepublishOnly, and to give everyone a chance to upgrade to newish versions of npm. There's no reason for people to stay on old versions of npm, even if for whatever reason they can't move off of old versions of Node. We've put a considerable amount of work into keeping npm backwards compatible all the way to Node 0.8. This is especially true for publishers, who need to keep reasonably up to date just so they have an npm that works with the current registry architecture.

I don't think it's especially onerous to include "in order to publish this package, you must be running at least npm@3.4.5" in CONTRIBUTING.md. If you do want to go the extra mile and support old versions of npm, having a dependency on in-publish doesn't seem terrible, either.

Finally, given how the lifecycle works, removing prepublish as an event would require special conditional logic and would violate the symmetry of the model, which would lead to yet more confusion and complaints (and the attendant support load that comes with that), so we're not going to do that.

Thanks for the detailed answer! If steps 1-3 make it onto 2.x, then I am content to not care about npm 1.

Sadly, CONTRIBUTING.md doesn't help me because documentation is advisory, not enforcement.

I don't understand the last paragraph, but I trust that you know the details far better than I :-)

Sadly, CONTRIBUTING.md doesn't help me because documentation is advisory, not enforcement.

To get a little more opinionated for a moment, if you can't get across to your collaborators the basic requirements for working with the code base, there are organizational problems that are far graver than the confusion arising from using inconsistent tool versions.

That's entirely true - but one could make the same argument about style, and yet using a linter to guarantee consistency is so common a practice that it's often considered bad practice to not do so. People are people, and checks that aren't automated by software will be occasionally skipped.

👍 to the proposal

👍 it's really hurting me in many projects

+1

Just saw it by accident, makes no sense to me at all. Now I have to run prepublish work manually to prevent the script from being run when another user installs my modules.

MIT License

Copyright (c) [year] [fullname]

Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to deal
in the Software without restriction, including without limitation the rights
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all
copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
SOFTWARE.