RFC: Never remove detection of outdated config keys (Config Lifecycle Management)
メンテナーはふだん 1 日以内に返信
まだ誰も着手していません。
評価
- 難易度
- 5/5
- 見積もり時間
- 1週間以上
- 初心者へのやさしさ
- 25/100
- issue の種類
- 機能追加
- 明瞭さ
- 説明が足りない
- 活発さ
- 活発
- 技術スタック
- javascript, nodejs
- 領域
- cli
調査の方向性
No repository files or tests are named. Start by locating npm's existing unknown-config-key warning and reviewing the proposed protocol and reference library; done would require an agreed catalog schema, lifecycle behavior, warning semantics, and a maintainer-approved implementation plan.
索引モデルが issue の本文から書いたものです。
説明
npm currently warns about unknown user config keys and says that support will stop in a future major version. That path ends with silent mystery debt: old projects keep the key, future npm stops mentioning it, and people copy unexplained lines into new files.
Please treat outdated config keys as a forever-detectable catalog problem—not something to delete from recognition.
Proposal: Config Lifecycle Management
Keep a shipped, machine-readable key index for every config key npm has ever recognized. Keys move through statuses; they are never removed from the index:
| Status | Behavior |
|---|---|
active |
Accept and document |
deprecated |
Accept; always warn with successor + timeline |
expired |
Do not apply the value; always detect and alert: expired after version X; ignored; migration path |
unknown |
Present in a scanned file but absent from the catalog — warn (typo / foreign tool / catalog gap) |
Non-negotiable: expired ≠ forgotten. Stopping detection after a major version is the failure mode.
Why this matters
- Old
.npmrc/ project config keeps outdated keys for years (archives, corporate templates, copied gists). - If npm stops warning, the key becomes unexplained folklore.
- Humans and AI agents then have to archaeology the meaning; careful users research, others copy blindly.
- npm already pays the cost of scanning config; preserving catalog rows is cheap compared to ecosystem confusion.
Concrete ask
- Never remove a known key from npm’s recognition/alert path. Change status instead.
- Ship a versioned config-keys index (JSON is fine) with releases and docs.
- Alerts must distinguish deprecated vs expired vs unknown, and for expired keys name the version boundary (e.g.
expired after [email protected]; value ignored). - Prefer one internal module for classify → match → alert so warnings stay consistent.
Prior art / reference
OpenShellOrg drafted this as a CLI config lifecycle protocol and a small reference library:
- Protocol: https://github.com/openshellorg/docs (page: Config Lifecycle Management / SOS mandatory protocols)
- Published docs: https://docs.opensh.org/open-shell-org/standard-config-lifecycle-management.html
- Reference library: https://github.com/openshellorg/config-lifecycle
- Practitioner write-up: https://docs.devcentr.org/general-knowledge/explanation/architecture/config-lifecycle-management/
Happy to refine the index schema with maintainers. The goal is explainability that outlives any single major version.
Originally filed under the name Config Key Sanitation; renamed to Config Lifecycle Management on 2026-09-26. Old links redirect.
- 主要言語
- JavaScript
- スター
- 10.1k
- フォーク
- 4.7k
- 平均マージ
- 3日 9時間
- マージ済み PR（30日）
- 9
環境構築
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
npm/cli のほかの issue
-
難易度 1/5 1時間未満 初心者へのやさしさ 80/100
メンテナーはふだん 1 日以内に返信
-
Engineering
難易度 2/5 1〜3時間 初心者へのやさしさ 75/100
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 70/100
メンテナーはふだん 1 日以内に返信
-
Bug Needs Triage
難易度 2/5 1〜3時間 初心者へのやさしさ 75/100
メンテナーはふだん 1 日以内に返信
-
[DOCS] `npm trust circle` docs should warn that OIDC token exchange in SSH reruns isn't supportedオープンDocumentation Needs Triage
難易度 2/5 1〜3時間 初心者へのやさしさ 68/100
メンテナーはふだん 1 日以内に返信
似ている issue
-
refactor
難易度 2/5 半日 初心者へのやさしさ 84/100
メンテナーはふだん 5 日以内に返信
-
translation
難易度 2/5 1〜3時間 初心者へのやさしさ 78/100
ciderapp/translations#87 · コメント 1 件 ·
-
難易度 2/5 1〜3時間 初心者へのやさしさ 88/100
メンテナーはふだん 1 日以内に返信
-
bug
難易度 2/5 1〜3時間 初心者へのやさしさ 67/100
メンテナーはふだん 1 日以内に返信
-
component: split-view platform: windows
難易度 2/5 1〜3時間 初心者へのやさしさ 74/100
zen-browser/desktop#15616 · リアクション 1 件 ·
メンテナーはふだん 1 日以内に返信