Replies: 7 comments · 4 replies
-
|
Stumbled across this while trying to solve this same issue. I'm genuinely surprised how there hasn't been traction on this yet |
Beta Was this translation helpful? Give feedback.
-
|
Same, this seems like essential functionality for components |
Beta Was this translation helpful? Give feedback.
-
|
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". 😄 |
Beta Was this translation helpful? Give feedback.
-
|
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. 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. |
Beta Was this translation helpful? Give feedback.
-
|
+1. This would be very useful in a lot of scenarios and critical in both:
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? |
Beta Was this translation helpful? Give feedback.
-
|
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? |
Beta Was this translation helpful? Give feedback.
-
|
+1 too. We published a private package on GHP, a package which we recently renamed from 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 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 emptyBut I get an error code E400 with a message NPMjs allows to simply mark a package as deprecated in its online package settings. 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. |
Beta Was this translation helpful? Give feedback.
-
|
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) |
Beta Was this translation helpful? Give feedback.
-
|
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 |
Beta Was this translation helpful? Give feedback.
-
|
+1 to this. Directly marking packages as deprecated would be a huge help for our team. |
Beta Was this translation helpful? Give feedback.
-
|
+1. We would really love to see this implemented |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
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!
Beta Was this translation helpful? Give feedback.
All reactions