An alternative to release perhaps that matches release consistency.
What's the use-case?
When np fails, like has happened with the past few versions.
https://github.com/sindresorhus/np/issues/422 and https://github.com/sindresorhus/np/issues/418
I don't think that's a good argument for adding a feature. The problems should be fixed instead. That being said, I'm open to adding this as it could be useful for non-Node.js projects.
When
npfails, like has happened with the past few versions.422 and #418
It can also fail independently of np. It just happened to me that I close the release draft browser tab by accident and cannot open it again. Also happened in the past.
@sindresorhus any ideas on the implementation?
We already have a releaseDraft flag to enable or disable github releases. Reusing this could cause confusions. But adding a flag with a similar name and purpose really doesn't make much sense.
Can we change the releaseDraft to mean if specified to just open the release url, and in case specified to be false to skip the whole process?
Any other ideas on how to implement this?
@sindresorhus any ideas on the implementation?
We already have areleaseDraftflag to enable or disable github releases. Reusing this could cause confusions. But adding a flag with a similar name and purpose really doesn't make much sense.
Can we change thereleaseDraftto mean if specified to just open the release url, and in case specified to be false to skip the whole process?
Any other ideas on how to implement this?
Seems sensible to skip default behavior if --release-draft is explicited. The same would be true for a hypothetical --yarn flag (I believe it is already the case that if --no-yarn is not present the service used depends on who called np).
I confirm this would be very useful to be able to trigger only the release draft.
My connection went down when pushing tags (just before triggering the draft) and I had to Ctrl+C the process. And now I have to manually write a release report...
Maybe you could add something like np --release-draft-only.
Edit: Actually, it wasn't a connection problem. I tested manually to push the tags and it prompted me to enter my git credentials. That was why the "Pushing tags" step was spinning infinitely. This is the same issue as #417.
I'm open to adding this as it could be useful for non-Node.js projects.
Wouldn't that be an argument for the extraction of this feature into its own package a-la release?