Thanks to visit codestin.com
Credit goes to github.com

Skip to content
This repository was archived by the owner on Aug 11, 2022. It is now read-only.

Add lifecycle script that actually runs before (and only before) prepublish #9722

Closed
wants to merge 1 commit into from

Conversation

dominictarr
Copy link

This PR adds a lifecycle script that runs before (and only before) publish.
This PR closes #8402
This PR does not break legacy behavior of prepublish script.
If merged, users who need a lifecycle script that actually runs before prepublish may opt into this change
by installing the latest npm and adding an "actuallyprepublish" script to their package.json.

If there is a better way to implement this change, please advise.
If you would merge this please let me know and I'll add documentation.

This PR supercedes this feature request #9721

There is a bit of a bikeshed about what this script should be called, I settled on actuallyprepublish but I considered prepublishliterally and pregoddamnpublish. Any other suggestions are welcome.

@ForbesLindesay
Copy link
Contributor

👍

@samccone
Copy link

👍 would be highly useful on many of my projects :)

@Fishrock123
Copy link
Contributor

This would be great. I've wanted to script actions that run prior to publish only on npm modules before but was unable to do so.

@iarna
Copy link
Contributor

iarna commented Oct 8, 2015

@othiym23 has been promising to drop by this issue…

But till then, https://www.npmjs.com/package/in-publish let's you do exactly this today without new lifecycles or backwards compatibility issues.

@dominictarr
Copy link
Author

@iarna thanks I am aware of in-publish, but reading it's code i see it's more complicated than my PR, and relies on a obscure npm api (i didn't know that the config is passed to the as JSON in an env var!)

I guess I'd be okay with in-publish (although that solution is uglier) if that was officially supported by npm.

Actually, I discussed this with @othiym23 at andyet conf the other day, he said he wouldn't merge this, because he did not want to add (more) cruft to npm, and that he was committed to (eventually) fixing this by changing the prepublish behavior. That is what i recall - I'll let @othiym23 correct me though.

I see his point of view, but i do disagree. Yes it is cruft, but npm already has lots of cruft. does it really hurt to have a little more, carefully considered cruft? If we graph cruft over time and measure the area under the graph, how do we minimize total cumulative cruft? I argue that a new script command is that minimal cruft solution.
offically supporting in-publish is a bit more crufty, in my opinion, but i'll reluctantly accept that otherwise...

@Fishrock123
Copy link
Contributor

RE: cruft, which node core also very carefully considers:

I always state that things that people need and are painful for users to make in userland probably belong in core. (Usually c++ things in our case.)

Considering this has been painful to people for literally years, and has only recently been solved by an employee of npm by using obscure workarounds, I personally think that fits the bill for taking it in.

(In one way or other.)

samccone referenced this pull request in yeoman/generator-polymer Oct 16, 2015
@othiym23 othiym23 self-assigned this Oct 19, 2015
@othiym23
Copy link
Contributor

Closing in favor of #10074. I hope the discussion in #10074 accurately captures the in-person discussion that you and I had about prepublish, @dominictarr. Thank you for that conversation and for putting this together, Let me know over there if you think I captured it incorrectly.

@othiym23 othiym23 closed this Oct 22, 2015
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants