NPM package deprecation

[leon-vg]

Select Topic Area

Product Feedback

Body

At our company, we use GitHub packages as our primary internal packages repository for NPM packages.

In the lifecycle of a package, it is important to be able to signal that a package has been deprecated. NPM has the npm deprecate command, but this does not seem to work with GitHub packages. See this Stack Overflow question for an example.

It would be great if this ability would be supported by GitHub packages!

[markscamilleri]

Stumbled across this while trying to solve this same issue. I'm genuinely surprised how there hasn't been traction on this yet ☹️

[liam1uphealth]

Same, this seems like essential functionality for components

[mlafleur]

I agree. Right now, we're stuck deleting the version entirely, which causes all sorts of deployment problems.

Not to mention making "removed because of a bug" pretty much indistinguishable from "removed because I was an idiot and deleted the wrong version". 😄

[ettaboyle]

Thanks for the original post @leon-vg and additional comment @markscamilleri 👋🏻

This community is managed by GitHub employees, but there is no SLA or guarantee each post will get a response from a community manager or product leader.

As this discussion provided product feedback or a feature request we encourage you to review the "Making Suggestions" guidelines in the repo readme including: "Once you kick off a discussion, the GitHub product team will evaluate the feedback but will not be able to respond to every submission."

That being said, I was to emphasize that we appreciate your feedback and your valuable input. We want to be transparent about our current priorities. You can gain insights into the projects we’re currently focusing on for the upcoming year by checking our public roadmap. While smaller fixes may not always be explicitly listed, they often get addressed when related work is in progress.

Regarding your specific request, it’s important to note that it’s not actively being worked on at the moment. However, this doesn’t mean we won’t consider it in the future; it’s simply not on our development roadmap right now.
We’d like to emphasize that as a valued GitHub user, your feedback in this Discussion space, along with appropriate tags and examples, plays a crucial role in shaping the development of GitHub. While we can’t guarantee immediate action on every piece of feedback, please rest assured that we are attentive to your suggestions and continuously strive to enhance the GitHub experience.
While we do review all incoming feedback unfortunately due to the volume of feedback, we may not be able to respond to each one individually at this time. However, we strongly encourage you to continue providing your valuable input as it greatly helps us prioritize and improve GitHub.

Your contributions are instrumental in making GitHub better for all users. Thank you for taking the time to share your thoughts with us, even if the particular request is not currently in active development. Your input is truly valuable and contributes to the continuous improvement of GitHub.

Thank you for contributing and continuing to support other users in the GitHub Community Discussions.

[tmadej]

+1. This would be very useful in a lot of scenarios and critical in both:

• larger private enterprise teams, or
• an open source package with a lot of consumers across many versions

I see that you mentioned there are no guarantees. When can we expect this to be prioritized on the roadmap or at least discussed to be considered?

[liam1uphealth]

Massive +1 here. I am fairly confused by the omissions of un-publishing or deprecating a component. Are we expected to just leave versions of components with bugs live? Or delete a repository every single time a bug is introduced in a certain version and recreate the library?

[olange]

+1 too. We published a private package on GHP, a package which we recently renamed from @‹scope›/‹oldPackageName› to @‹scope›/‹newPackageName›.

Now we'd like to mark the package versions published with the «old» name as being deprecated, to signal clearly to our users that they should use the new name, would they accidentally try to npm install @‹scope›/‹oldPackageName›.

However, we don't want to delete the package versions published with the «old» name — to be able to build ancient versions of the code.

Following the docs of npm deprecate, I expected it would be as easy as:

% npm deprecate @‹scope›/‹oldPackageName›@1.x "Renamed to @‹scope›/‹newPackageName›" --registry=https://npm.pkg.github.com 
npm error code E400
npm error 400 Bad Request - PUT https://npm.pkg.github.com/@‹scope›%2f‹oldPackageName› - unmarshalling packument failed: version.ID cannot be empty

But I get an error code E400 with a message […] unmarshalling packument failed: version.ID cannot be empty, which is quite confusing. What does it mean?

NPMjs allows to simply mark a package as deprecated in its online package settings.
One would expect we could do the same on the online package settings on GHP.

Looked at the above mentioned StackOverflow unanswered question, studied GHP package metadata (an instructive read), re-read the «Working with the npm registry» GHP docs, got lost wondering whether package tags could help? (no), then found this discussion. Will report if I find something else.

[olange]

Looking at the REST API endpoints for packages, I tried the following and I got the package details:

GH_TOKEN=‹USER_ACCESS_TOKEN› gh api -X GET /orgs/‹owner›/packages/npm/‹oldPackageName› 

{
  "id": ‹oldPackageId›,
  "name": "‹oldPackageName›",
  "package_type": "npm",
  …
}

Then I tried to hack the request, to PATCH instead of GETting the package data, but it does not work; note I tried patching the «package entity», not the «package version entity», which is probably the entity I should actually patch:

GH_TOKEN=‹USER_ACCESS_TOKEN› gh api -X PATCH /orgs/‹owner›/packages/npm/‹oldPackageName› -f 'data={"deprecated":true}' 

{
  "message": "Not Found",
  "documentation_url": "https://docs.github.com/rest",
  "status": "404"
}
gh: Not Found (HTTP 404)

[olange]

Looking at https://github.com/‹owner›/‹repoName›/pkgs/npm/‹packageName›/versions, I could retrieve the PACKAGE_VERSION_ID from the URL of the version detail page. This worked:

GH_TOKEN=‹USER_ACCESS_TOKEN› gh api -X GET /orgs/‹owner›/packages/npm/‹oldPackageName›/versions/‹PACKAGE_VERSION_ID›

{
  "id": ‹PACKAGE_VERSION_ID›,
  "name": "‹VERSION›",
  "url": "https://api.github.com/orgs/‹owner›/packages/npm/‹oldPackageName›/versions/‹PACKAGE_VERSION_ID›",
  "package_html_url": "https://github.com/orgs/‹owner›/packages/npm/package/‹oldPackageName›",
  "license": "Apache-2.0",
  "created_at": "2024-10-24T16:11:53Z",
  "updated_at": "2024-10-24T16:11:53Z",
  "html_url": "https://github.com/orgs/‹owner›/packages/npm/‹oldPackageName›/‹PACKAGE_VERSION_ID›",
  "metadata": {
    "package_type": "npm"
  }
}

But the PATCH still returns a HTTP 404 error code:

GH_TOKEN=‹USER_ACCESS_TOKEN› gh api -X PATCH /orgs/‹owner›/packages/npm/‹oldPackageName›/versions/‹PACKAGE_VERSION_ID› -f 'data={"deprecated":true}'

{
  "message": "Not Found",
  "documentation_url": "https://docs.github.com/rest",
  "status": "404"
}

Sharing these unsuccessful experiences, may be a better inspired person will find a way to set the "deprecated": true property on the package version in the GHP thru GitHub's REST API.

[fdeters]

+1 to this. Directly marking packages as deprecated would be a huge help for our team.

[m1rm]

+1. We would really love to see this implemented