Changes to npm Unpublish Policy - January 2020

TL;DR

Until today, you couldn’t unpublish packages, or package versions, older than 72 hours without contacting support (background available here and here). Because this is our most popular support request, we’ve extended the ability for you to unpublish packages beyond 72 hours if your package meets certain criteria.

What are we doing?

npm has grown a lot over the past 10 years, and rapid growth means lots of support requests! We’re taking some time to revisit and improve our workflows and to give more power to our users with self-service features. One of our most common support requests is to unpublish packages that have aged out of our 72 hour grace period. In the past, we have addressed these requests on a case-by-case basis, and starting today you can now do this yourself if your package meets the following criteria:

• Has no package dependents in the npm Public Registry
  
• Has fewer than 300 downloads over the past week
  
• Has a single owner/maintainer
  

As before, you can still unpublish packages younger than 72 hours as long as there are no dependents in the public registry, regardless of package ownership or download count. This policy update only applies to packages older than 72 hours.

Why these criteria?

A good chunk of the unpublish requests that support receives meet these criteria. We’ve taken the manual decision tree that our support team has developed over the years and incorporated that back into the registry it to give you more agency over your packages.

Why 300 downloads?

In our experience, 300 downloads over the prior week is the right threshold for safely automating the removal of a package or package version from the registry.

Why single owner/maintainer?

Since there is no human arbiter involved in the process, we are erring on the side of caution. This is our first iteration, and we wanted to limit the scope of change.

Why zero package dependents?

The JavaScript ecosystem is built on trust, we are all standing on the shoulders of giants. As such, we don’t want to break downstream dependencies. However, people publish things by mistake all the time, and if there are no dependents, we want to let them unpublish. 

What does this mean for you?

This is an update to our existing unpublish policy for the npm Public Registry. This involves no changes to the CLI interface and you don’t have to update your CLI to benefit from these improvements. The registry will now let you unpublish an entire package, or package version under a broader set of criteria. If your package does not meet these criteria––for example, if you have multiple maintainers––you can still contact support to address the issue.

As always, once you have unpublished, you cannot undo the unpublish, or republish with any of the unpublished version numbers.

Questions? Concerns? Happy Dance?

We hope that the new unpublish policy improves your experience with npm. This is the first step towards delivering more self-service options for package publishers. Stay tuned for more news. 

As always, we’d love to hear from you if you. If you have questions or concerns, let us know at https://npm.community/ ›