npm Unpublish Policy

This document describes your options when looking to unpublish a package published to the public registry.

Registry data is immutable, meaning once published, a package cannot change. We do this for reasons of security and stability of the users who depend on those packages. So if you've ever published a package called "bob" at version 1.1.0, no other package can ever be published with that name at that version. This is true even if that package is unpublished.

However, because accidents happen, we allow you to unpublish packages in the situations described below. Otherwise, you can always deprecate a package.

Packages published less than 72 hours ago

For newly created packages, as long as no other packages in the npm Public Registry depend on your package, you can unpublish anytime within the first 72 hours after publishing.

Packages published more than 72 hours ago

Regardless of how long ago a package was published, you can unpublish a package that meets all of the following conditions:

• no other packages in the npm Public Registry depend on it
• it had less than 300 downloads over the last week
• it has a single owner/maintainer

How to unpublish

To unpublish a single package version, run npm unpublish <package_name>@<version>.

If all the versions of a package can be unpublished, you can unpublish all versions at once by running npm unpublish <package_name> --force.

Considerations:

• Once package@version has been used, you can never use it again. You must publish a new version even if you unpublished the old one.
• Once you have unpublished a package, you will not be able to undo the unpublish.
• If you entirely unpublish all versions of a package, you may not publish any new versions of that package until 24 hours have passed.

What to do if your package does not meet the unpublish criteria?

If your package does not meet the unpublish policy criteria, we recommend deprecating the package. This allows the package to be downloaded but publishes a clear warning message (that you get to write) every time the package is downloaded, and on the package's npmjs.com page. Users will know that you do not recommend they use the package, but if they are depending on it their builds will not break. We consider this a good compromise between reliability and author control.

This can be achieved by using one of the following from your command line:

• npm deprecate <package> "<message>" to deprecate the entire package
• npm deprecate <package>@<version> "<message>" to deprecate a specific version

If the entire package is deprecated, the package name will be dropped from our search results.

More on our unpublish policy

This document is additive to the unpublish procedures, the CLI commands unpublish documentation and the "Changes to npm Unpublish Policy - January 2020" blog post.

Issues?

If for some reason your package meets the unpublish policy criteria but the unpublish command fails, or if you need assistance with the deprecate process, please reach out to our support team where we'll be happy to assist.

If you believe a package violates npm's terms or policies, such as our terms of use, reach out to our support team. If a package infringes your copyright, refer to npm's DMCA takedown policy. If you believe a package violates your privacy rights, contact our privacy team as soon as possible.

Changes

This is a living document and may be updated from time to time. Please refer to the git history for this document to view the changes.

License

Copyright (C) npm, Inc., All rights reserved

This document may be reused under a Creative Commons Attribution-ShareAlike License.