rfcs
rfcs copied to clipboard
npm
For unpublished versions, have registry return 410 Gone and clients re-resolve semantic version
Unpublished packages currently cause pain for NPM users. A recommended approach ends up being to delete your lock file and re-generate it, which can cause a huge amount of dependencies to change when only one was needed.
Unpublished packages currently return the HTTP status code "404 Not Found". This code is designed for resources that might exist again in the future. In the NPM ecosystem, version numbers are wisely immutable. A better HTTP status code to return for an unpublished package is "410 Gone", designed for resources that will never come back.
When npm encounters a 410 Gone resource, it could try to resolve the related semantic version again, possibly selecting a newer version, fixing the issue for the single dependency without requiring regenerating the entire lock file.
To clarify, this proposal is only for tarball URLs for specific versions. If you do npm unpublish -f foo, then the request to https://registry.npmjs.org/foo should return a 404, not a 410, because someone else can publish new versions of foo (though, importantly, then cannot reuse old version numbers, and thus cannot take over the same tarball URLS - those are gone for good.)
I'm gonna /cc @bonkydog on this one, since it relates to their team. But my completely nonofficial position on this is that I like it, pending Brian's team's approval 👍
Brief update: We've moved this internally to appropriate channels and we'll be doing an internal review + prioritization of this feature. No timeline until that's done.
There is some internal work happening on the registry around unpublishing packages. To that effect, there is some changes happening around the status codes as well. There is an action item from https://github.com/npm/rfcs/issues/70 that will follow up with that feature team to make sure this gets added or at least addressed.
In a similar aspect - if a package is deprecated in place of another package could we use a redirect code (301 or 308)? It could definitely be a security issue if we allow users to redirect their packages, so maybe instead it errors but also provides the recommended alternative library? (should I open a secondary RFC for this or is it relevant enough to this one?)
I would issue a HTTP Redirect response sparingly-- only in a case where a module was found to have a security flaw and there's a known replacement which works exactly the same but lacks the security flaw.
Just to clarify the discussion between @seldo and me regarding url reuse, that was about unpublishing all versions of a package. Ie, if you do npm unpublish -f foo, then the request to https://registry.npmjs.org/foo should return a 404, not a 410, because someone else can publish new versions of foo (though, importantly, then cannot reuse old version numbers, and thus cannot take over the same tarball urls - those are gone for good.)
Responding with a 410 response code to tarball urls for deleted package versions is entirely appropriate, and I don't see any reason to oppose the fallback logic described in this RFC, but may have some feedback when we start trying to implement it.
The first step, of course, is to see if we can get the registry to respond with a 410 to deleted tarball requests,
Good clarification @isaacs. I've updated the RFC to clarify that the scope is restricted to tarball URLs and include your note that completely removing a package is a different case.