-
Notifications
You must be signed in to change notification settings - Fork 236
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
RFC: npm publish, unpublish, and [republish] functionality change #687
Open
ganeshkbhat
wants to merge
4
commits into
npm:main
Choose a base branch
from
apprepute:main
base: main
Could not load branches
Branch not found: {{ refName }}
Could not load tags
Nothing to show
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Open
Changes from 1 commit
Commits
Show all changes
4 commits
Select commit
Hold shift + click to select a range
c94efd8
RFC: npm publish, unpublish, and deprecate functionality and data/rep…
ganeshkbhat 4a6e075
[RFC] Redirect installation of Package A to installation of Package B…
ganeshkbhat c1569e8
RFC: npm publish, unpublish, and deprecate functionality and data/rep…
ganeshkbhat 9b3cdb1
[RFC] Redirect Package A installation to Package B using a redirect i…
ganeshkbhat File filter
Filter by extension
Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
There are no files selected for viewing
89 changes: 89 additions & 0 deletions
89
accepted/0000-template-republish-npm-package-after-unpublish.md
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,89 @@ | ||
| # RFC: npm publish, unpublish, and deprecate functionality and data/repository management and log management policy (security policy) changes | ||
|
|
||
| ## Summary | ||
|
|
||
| When I publish a package v1.0.0 and unpublish it, it is unpublished correctly. However, I am not able to re-publish any other codebase B/ C/ D into v1.0.0. I will not be able to re-publish the same version v1.0.0 with a new or same codebase. | ||
|
|
||
| This RFC is a proposal where I recommend allowing republishing the same npm package version v1.0.0 with a different codebase B after unpublishing a version v1.0.0 with codebase A; with a possibility to view the publish, unpublish, republish logs/ codebase, etc. This recommended change improves the npm package publish-unpublish process, (historical) publish-unpublish data management policy, and (historical) publish-unpublish log management policy (and security management policy). | ||
|
|
||
|
|
||
| ## Motivation | ||
|
|
||
| Allowing republishing the same npm package version v1.0.0 with a different codebase B after unpublishing a version v1.0.0 with codebase A; with a possibility to view the publish, unpublish, republish logs/ codebase, etc. This recommended change improves the npm package publish-unpublish process, (historical) publish-unpublish data management policy, and (historical) publish-unpublish log management policy (and security management policy). | ||
|
|
||
| This is a `npm publish, unpublish, and deprecate functionality and data/repository management plus log management policy (security policy) changes request`. | ||
|
|
||
|
|
||
| ## Detailed Explanation | ||
|
|
||
| npm publish, unpublish, and deprecate functionality needs/ requirement: | ||
|
|
||
| - When I publish a package v1.0.0 and deprecate it, it is deprecated correctly. I will not be able to publish any other version into v1.0.0. | ||
| - When I publish a package v1.0.0 and unpublish it, it is unpublished correctly. However, I am not able to re-publish any other codebase into V1.0.0. I will not be able to re-pulish the same version v1.0.0. | ||
|
|
||
| I recommend allowing republishing the same npm package version v1.0.0 with a different codebase B after unpublishing a version v1.0.0 with codebase A; with a possibility to view the publish, unpublish, republish logs/ codebase, etc. | ||
|
|
||
| While being unable to republish a unpublished version v1.0.0 is the current behaviour, I believe being able to re-publish a different codebase with the same version v1.0.0 after unpublish should be possible. If you are archiving publish and unpublish logs plus codebase internally in your servers for security reasons and/ or other policy reasons, I suggest you could probably archive into the servers the published-unpublished version v1.0.0, the unpublished v1.0.0 codebase A, new v1.0.0 published codebase B, and future unpublish logs, so on, for the version v1.0.0, etc. | ||
|
|
||
|
|
||
| ### Environment (when raising the change proposal) | ||
|
|
||
| - npm: v8.15.0 (applies to all versions) | ||
| - Node.js: v18.10.0 (applies to all versions supported or historical) | ||
| - OS Name: Microsoft Windows NT 10.0.22621.0 x64, Linux, Mac (applies to all versions supported) | ||
| - System Model Name: Dell Microsoft Windows 11 (applies to all versions supported) | ||
| - npm config: defaults | ||
| ```ini | ||
| ; "builtin" config from C:\Users\GB\Documents\binaries\node\node_modules\npm\npmrc | ||
|
|
||
| prefix = "C:\\Users\\GB\\AppData\\Roaming\\npm" | ||
|
|
||
| ; "user" config from C:\Users\GB\.npmrc | ||
|
|
||
| //registry.npmjs.org/:_authToken = (protected) | ||
| msvs_version = "2019" | ||
| python = "python3.8" | ||
|
|
||
| ; node bin location = C:\Users\GB\Documents\binaries\node\node.exe | ||
| ; node version = v18.10.0 | ||
| ; npm local prefix = C:\Users\GB | ||
| ; npm version = 8.15.0 | ||
| ; cwd = C:\Users\GB | ||
| ; HOME = C:\Users\GB | ||
| ; Run `npm config ls -l` to show all defaults. | ||
| ``` | ||
|
|
||
|
|
||
| ## Rationale and Alternatives | ||
|
|
||
| None | ||
|
|
||
|
|
||
| ## Implementation | ||
|
|
||
| While being unable to republish a unpublished version v1.0.0 is the current behaviour, I believe being able to re-publish a different codebase with the same version v1.0.0 after unpublish should be possible. | ||
|
|
||
| The implementation will include: | ||
|
|
||
| - Allow re-publishing a different codebase B with the same version v1.0.0 after unpublishing should be possible. | ||
| - If you are archiving publish and unpublish logs internally in your servers for security reasons and/ or other policy reasons, I suggest you could probably archive into the servers the published-unpublished version v1.0.0, future unpublish logs, so on, for the version v1.0.0, etc. | ||
| - If you are archiving publish and unpublish repositories/ codebase internally in your servers for security reasons and/ or other policy reasons, I suggest you could probably archive into the servers the published-unpublished version v1.0.0, the unpublished v1.0.0 codebase A, new v1.0.0 published codebase B, and future unpublish codebases B, so on, for the version v1.0.0, etc. | ||
| - Let users see appropriate publish-unpublish-republish logs for their application (dependent package) security and implementation reasons. | ||
| - Optionally, allow users to (preferably) download (as compressed package) the unpublished package in case of specific needs of usage/ local installations. | ||
| - Optionally, allow users to (!complexity, take care) install the unpublished package probably using a hash (packagename@v1.0.0:jk45k45b54dsdfvc5vsjk45kj=) in case of specific needs of usage/ local installations. | ||
|
|
||
| [https://docs.npmjs.com/policies/unpublish](https://docs.npmjs.com/policies/unpublish) | ||
|
|
||
|
|
||
| ## Prior Art | ||
|
|
||
| NA | ||
|
|
||
|
|
||
| ## Unresolved Questions and Bikeshedding | ||
|
|
||
| - Is there a policy issue that is effected or affected for the repository data management or security logs? | ||
| - This recommended change improves the npm package publish-unpublish process, (historical) publish-unpublish data management policy, and (historical) publish-unpublish log management policy (and security management policy). | ||
| - Is there a recommended repository data management or security logs management process recommendation? | ||
| - If you are archiving publish and unpublish logs plus codebase internally in your servers for security reasons and/ or other policy reasons, I suggest you could probably archive into the servers the published-unpublished version v1.0.0, the unpublished v1.0.0 codebase A, new v1.0.0 published codebase B, and future unpublish logs, so on, for the version v1.0.0, etc. [https://docs.npmjs.com/policies/unpublish](https://docs.npmjs.com/policies/unpublish) | ||
|
|
||
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is good and intended. While it may suck as a publisher (I recently had to help internally with an ancient mispublish that bumped a semver minor, meaning we had to go straight to 4.8.0 rather than starting at 4.0.0!), the existing approach is very rarely an issue, is a simpler solution, and is less potentially harmful than what's proposed here IMO.