-
Notifications
You must be signed in to change notification settings - Fork 3.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[BUG] npm unpublish
should warn about mandatory 24-hour waiting period
#958
Comments
Unpublished package versions may never be reused; “24 hours” may be referring to a period (that is now much longer) within which a package version can be unpublished? |
@ljharb I get the same error, even when I bump the package version:
|
Hmm, that’s very confusing. Do you have any remaining published versions? Or did you unpublish every version of it? |
Nope. This is a new module. The one/only version I've published is v1.0.0. I unpublished that version, tried to republish, failed, then tried to publish as v1.0.1, but that and subsequent attempts have all failed. |
Ah, gotcha. The 24 hour period must apply to fully unpublished packages. What I generally do regardless (for future reference) is always publish the new version before unpublishing the old one. |
npm If your bug is preproducible on If your issue was a feature request, please consider opening a new RRFC or RFC. If your issue was a question or other idea that was not CLI-specific, consider opening a discussion on our feedback repo Closing: This is an automated message. |
I'm pretty sure this one is still applicable to v7, so I'll reopen and tag as such. |
Currently npm does not prompt you when unpublishing, so adding something like that would constitute quite a breaking change. If this is still something you feel strongly about and would like to see added to npm in a future release, please open up an rrfc or rfc in our rfc repo. |
@wraithgar i don't think printing a warning, without a prompt, would be a breaking change. |
@ljharb There was just a discussion at the last rfc meeting about the merits of warnings like this, so I still think an rfc discussion is the right place to make this decision. |
+1 |
Just hit this today, it would be great to have a warning or error as there is a major cost to consumers of libraries that unpublish versions now having to wait 24 hours to get an update. |
Would be great if we could add a warning for this. I removed a package and republished it for some internal reasons and now I have to wait 24 hours - how could I have known this was a thing. |
+1 to adding the warning as we ran into this and searching online led me to this issue. |
A warning in the cli is likely not going to be approved because this policy is only related to one of the many registries that npm supports. This policy is only for the npm registry itself, not the github packages registry for example. We would have a mechanism for a registry sending a response during unpublish that gets logged, and npm already supports this via the |
Okay, arguments about the wisdom of allowing modules to be unpublished aside, I recently found myself wanting to "republish" a new module I'd created (
persistentmap
) bynpm unpublish
'ing it, making a couple edits, thennpm publish
ing it under the same version. (I know, I know... I wanted to just tweak a few things in the README. Shoot me.)Aside from the expected warning about needing to use
--force
, theunpublish
action worked fine. However when I went to republish it, I was a met with the following:I'm sure there are good and valid reasons for this waiting period - I'm not arguing that - but to not have any warning about it was an unpleasant shock. In my case this isn't a big deal - nobody is using
persistentmap
yet so, fine whatever, but this could have been problematic had I decided to try this with a package that had dependents.(Again, let's assume for the moment that most NPM users are, like me, willing to do stupid things they probably shouldn't be doing in the first place.)
It would have been nice to have had a warning about this. E.g.
The text was updated successfully, but these errors were encountered: