From c94efd80fac4327e719b466c6029ba4a92987032 Mon Sep 17 00:00:00 2001 From: Ganesh K Bhat Date: Wed, 5 Apr 2023 09:03:39 +0530 Subject: [PATCH 1/4] RFC: npm publish, unpublish, and deprecate functionality and data/repository management and log management policy (security policy) changes. --- ...e-republish-npm-package-after-unpublish.md | 89 +++++++++++++++++++ 1 file changed, 89 insertions(+) create mode 100644 accepted/0000-template-republish-npm-package-after-unpublish.md diff --git a/accepted/0000-template-republish-npm-package-after-unpublish.md b/accepted/0000-template-republish-npm-package-after-unpublish.md new file mode 100644 index 00000000..4d178d23 --- /dev/null +++ b/accepted/0000-template-republish-npm-package-after-unpublish.md @@ -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) + From 4a6e0756fe26e363d09f1210ea81bef0ee705d14 Mon Sep 17 00:00:00 2001 From: Ganesh K Bhat Date: Thu, 6 Apr 2023 00:32:10 +0530 Subject: [PATCH 2/4] [RFC] Redirect installation of Package A to installation of Package B using redirect key specification inpackage.json --- ...kage-b-on-specification-in-package.json.md | 227 ++++++++++++++++++ 1 file changed, 227 insertions(+) create mode 100644 accepted/0000-template-redirect-package-a-to-package-b-on-specification-in-package.json.md diff --git a/accepted/0000-template-redirect-package-a-to-package-b-on-specification-in-package.json.md b/accepted/0000-template-redirect-package-a-to-package-b-on-specification-in-package.json.md new file mode 100644 index 00000000..2c799de5 --- /dev/null +++ b/accepted/0000-template-redirect-package-a-to-package-b-on-specification-in-package.json.md @@ -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 ajs and bjs. Due to some reason I intend to merge both. Right now, I am installing ajs with npm install ajs and bjs with npm install bjs. But after the merge I wish to install bjs when ajs (npm i ajs) is installed. + +Allow redirecting a package A to Package B while installation using a key in a package.json specification. This feature should allow for installong Package B when a installation of Package A is made from npm. + +I am aware of manual installation of `npm i @npm:`. 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 + +NA + From c1569e847be34fa99bcd1f7a7e37a23a418c510f Mon Sep 17 00:00:00 2001 From: Ganesh K Bhat Date: Thu, 6 Apr 2023 00:32:43 +0530 Subject: [PATCH 3/4] RFC: npm publish, unpublish, and deprecate functionality and data/repository management and log management policy (security policy) changes. --- ...ckage-a-to-package-b-on-specification-in-package.json.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/accepted/0000-template-redirect-package-a-to-package-b-on-specification-in-package.json.md b/accepted/0000-template-redirect-package-a-to-package-b-on-specification-in-package.json.md index 2c799de5..623db619 100644 --- a/accepted/0000-template-redirect-package-a-to-package-b-on-specification-in-package.json.md +++ b/accepted/0000-template-redirect-package-a-to-package-b-on-specification-in-package.json.md @@ -14,9 +14,9 @@ The RFC recommentation allows for `redirecting` a `package A` to Package B while ## Detailed Explanation -I have two packages ajs and bjs. Due to some reason I intend to merge both. Right now, I am installing ajs with npm install ajs and bjs with npm install bjs. But after the merge I wish to install bjs when ajs (npm i ajs) is installed. +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. -Allow redirecting a package A to Package B while installation using a key in a package.json specification. This feature should allow for installong Package B when a installation of Package A is made from npm. +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 @npm:`. 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. @@ -223,5 +223,5 @@ NA ## Unresolved Questions and Bikeshedding -NA +Open for discussion. From 9b3cdb11f2b5742dcbd2f4e698f134557e5df5ba Mon Sep 17 00:00:00 2001 From: Ganesh K Bhat Date: Thu, 6 Apr 2023 00:35:52 +0530 Subject: [PATCH 4/4] [RFC] Redirect Package A installation to Package B using a redirect install key specification in package.json is made. --- ...t-package-a-to-package-b-on-specification-in-package.json.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/accepted/0000-template-redirect-package-a-to-package-b-on-specification-in-package.json.md b/accepted/0000-template-redirect-package-a-to-package-b-on-specification-in-package.json.md index 623db619..21478f90 100644 --- a/accepted/0000-template-redirect-package-a-to-package-b-on-specification-in-package.json.md +++ b/accepted/0000-template-redirect-package-a-to-package-b-on-specification-in-package.json.md @@ -3,7 +3,7 @@ ## 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