-
Notifications
You must be signed in to change notification settings - Fork 239
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 }}
Loading
Could not load tags
Nothing to show
Loading
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 all commits
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…
4a6e075
[RFC] Redirect installation of Package A to installation of Package B…
c1569e8
RFC: npm publish, unpublish, and deprecate functionality and data/rep…
9b3cdb1
[RFC] Redirect Package A installation to Package B using a redirect i…
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
227 changes: 227 additions & 0 deletions
227
...00-template-redirect-package-a-to-package-b-on-specification-in-package.json.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,227 @@ | ||
# REDIRECT PACKAGE A TO PACKAGE B ON SPECIFICATION KEY IN PACKAGE.JSON | ||
|
||
## Summary | ||
|
||
The RFC recommentation allows for `redirecting` a `package A` to Package B while installation using a key in a `package.json` specification. This feature should install `Package B` when a installation of `Package A` is made from npm. | ||
|
||
|
||
## Motivation | ||
|
||
- Move systematically to another package. | ||
- Stopping maintainence or stopping a package in favour of another package. | ||
- Name reuse and Name change related branding or traction issues. | ||
|
||
|
||
## Detailed Explanation | ||
|
||
I have two packages `a.js` and `b.js`. Due to some reason I intend to merge both. Right now, I am installing `a.js` with `npm install a.js` and `b.js` with `npm install b.js`. But after the merge I wish to install `b.js` when `ajs` (`npm i a.js`) is installed. | ||
|
||
The RFC recommentation allows for `redirecting` a `package A` to Package B while installation using a key in a `package.json` specification. This feature should install `Package B` when a installation of `Package A` is made from npm. | ||
|
||
I am aware of manual installation of `npm i <alias>@npm:<package>`. It does not solve my purpose. I wish not to copy one repo `packagea` to another to maintain the sanity of the deprecated repository upgraded to another `packageb`. The only option I see is update the github url in the repository. But I doubt it solves the purpose. Any help is welcome. | ||
|
||
So when `npm install packagea` is made it is install `packageb` if the `packagea` has a key for `redirect` or `redirectInstall` as a key specification something like below. | ||
|
||
Package A's `package.json` specification: | ||
|
||
``` | ||
{ | ||
... | ||
redirectInstall: packageb, | ||
... | ||
} | ||
``` | ||
|
||
|
||
https://stackoverflow.com/questions/72554667/install-package-x-when-a-request-for-package-y-installation-is-made | ||
|
||
|
||
- npm: 8.5.5 | ||
- Node.js: 16.15.0 | ||
- OS Name: Windows/Linux | ||
- System Model Name: Dell Vostro OEM 3590 - i5 x64 Arch | ||
- npm config: | ||
|
||
```ini | ||
; copy and paste output from `npm config ls` here | ||
; node bin location = C:\Users\ganes\OneDrive\Documents\binaries\node\node.exe | ||
; cwd = C:\Users\ganes\OneDrive\Documents\projects\github\cgi-js | ||
; HOME = C:\Users\ganes | ||
; Run `npm config ls -l` to show all defaults. | ||
|
||
C:\Users\ganes\OneDrive\Documents\projects\github\cgi-js>npm config ls -l | ||
; "default" config from default values | ||
|
||
_auth = (protected) | ||
access = null | ||
all = false | ||
allow-same-version = false | ||
also = null | ||
audit = true | ||
audit-level = null | ||
auth-type = "legacy" | ||
before = null | ||
bin-links = true | ||
browser = null | ||
ca = null | ||
cache = "C:\\Users\\ganes\\AppData\\Local\\npm-cache" | ||
cache-max = null | ||
cache-min = 0 | ||
cafile = null | ||
call = "" | ||
cert = null | ||
ci-name = null | ||
cidr = null | ||
color = true | ||
commit-hooks = true | ||
depth = null | ||
description = true | ||
dev = false | ||
diff = [] | ||
diff-dst-prefix = "b/" | ||
diff-ignore-all-space = false | ||
diff-name-only = false | ||
diff-no-prefix = false | ||
diff-src-prefix = "a/" | ||
diff-text = false | ||
diff-unified = 3 | ||
dry-run = false | ||
editor = "notepad.exe" | ||
engine-strict = false | ||
fetch-retries = 2 | ||
fetch-retry-factor = 10 | ||
fetch-retry-maxtimeout = 60000 | ||
fetch-retry-mintimeout = 10000 | ||
fetch-timeout = 300000 | ||
force = false | ||
foreground-scripts = false | ||
format-package-lock = true | ||
fund = true | ||
git = "git" | ||
git-tag-version = true | ||
global = false | ||
global-style = false | ||
globalconfig = "C:\\Users\\ganes\\OneDrive\\Documents\\binaries\\node\\etc\\npmrc" | ||
heading = "npm" | ||
https-proxy = null | ||
if-present = false | ||
ignore-scripts = false | ||
include = [] | ||
include-staged = false | ||
include-workspace-root = false | ||
init-author-email = "" | ||
init-author-name = "" | ||
init-author-url = "" | ||
init-license = "ISC" | ||
init-module = "C:\\Users\\ganes\\.npm-init.js" | ||
init-version = "1.0.0" | ||
init.author.email = "" | ||
init.author.name = "" | ||
init.author.url = "" | ||
init.license = "ISC" | ||
init.module = "C:\\Users\\ganes\\.npm-init.js" | ||
init.version = "1.0.0" | ||
json = false | ||
key = null | ||
legacy-bundling = false | ||
legacy-peer-deps = false | ||
link = false | ||
local-address = null | ||
location = "user" | ||
lockfile-version = null | ||
loglevel = "notice" | ||
logs-max = 10 | ||
; long = false ; overridden by cli | ||
maxsockets = 15 | ||
message = "%s" | ||
metrics-registry = "https://registry.npmjs.org/" | ||
node-options = null | ||
node-version = "v16.15.0" | ||
noproxy = [""] | ||
npm-version = "8.5.5" | ||
offline = false | ||
omit = [] | ||
only = null | ||
optional = null | ||
otp = null | ||
pack-destination = "." | ||
package = [] | ||
package-lock = true | ||
package-lock-only = false | ||
parseable = false | ||
prefer-offline = false | ||
prefer-online = false | ||
prefix = "C:\\Users\\ganes\\OneDrive\\Documents\\binaries\\node" | ||
preid = "" | ||
production = null | ||
progress = true | ||
proxy = null | ||
read-only = false | ||
rebuild-bundle = true | ||
registry = "https://registry.npmjs.org/" | ||
save = true | ||
save-bundle = false | ||
save-dev = false | ||
save-exact = false | ||
save-optional = false | ||
save-peer = false | ||
save-prefix = "^" | ||
save-prod = false | ||
scope = "" | ||
script-shell = null | ||
searchexclude = "" | ||
searchlimit = 20 | ||
searchopts = "" | ||
searchstaleness = 900 | ||
shell = "C:\\Windows\\system32\\cmd.exe" | ||
shrinkwrap = true | ||
sign-git-commit = false | ||
sign-git-tag = false | ||
sso-poll-frequency = 500 | ||
sso-type = "oauth" | ||
strict-peer-deps = false | ||
strict-ssl = true | ||
tag = "latest" | ||
tag-version-prefix = "v" | ||
timing = false | ||
tmp = "C:\\Users\\ganes\\AppData\\Local\\Temp" | ||
umask = 0 | ||
unicode = true | ||
update-notifier = true | ||
usage = false | ||
user-agent = "npm/{npm-version} node/{node-version} {platform} {arch} workspaces/{workspaces} {ci}" | ||
userconfig = "C:\\Users\\ganes\\.npmrc" | ||
version = false | ||
versions = false | ||
viewer = "browser" | ||
which = null | ||
workspace = [] | ||
workspaces = null | ||
yes = null | ||
|
||
; "cli" config from command line options | ||
|
||
long = true | ||
``` | ||
|
||
|
||
## Rationale and Alternatives | ||
|
||
NA | ||
|
||
|
||
## Implementation | ||
|
||
|
||
Add documentation to redirect installation of one package(a.js) when installing another(b.js) package. | ||
|
||
|
||
## Prior Art | ||
|
||
NA | ||
|
||
|
||
## Unresolved Questions and Bikeshedding | ||
|
||
Open for discussion. | ||
|
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 ([email protected]: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.