Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

RFC: Never remove detection of outdated config keys (Config Lifecycle Management)

Chiusa
  • Qualcosa non va?
#10,045 3 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 2 giorni

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
25/100
Tipo di issue
Funzionalità
Chiarezza
Da chiarire
Stato di attività
Attiva
Stack tecnologico
javascript, nodejs
Ambito
cli

Direzione di ricerca

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.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

Needs Triage

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

  1. Old .npmrc / project config keeps outdated keys for years (archives, corporate templates, copied gists).
  2. If npm stops warning, the key becomes unexplained folklore.
  3. Humans and AI agents then have to archaeology the meaning; careful users research, others copy blindly.
  4. npm already pays the cost of scanning config; preserving catalog rows is cheap compared to ecosystem confusion.

Concrete ask

  1. Never remove a known key from npm’s recognition/alert path. Change status instead.
  2. Ship a versioned config-keys index (JSON is fine) with releases and docs.
  3. Alerts must distinguish deprecated vs expired vs unknown, and for expired keys name the version boundary (e.g. expired after [email protected]; value ignored).
  4. 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:

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.

Lingua principale
JavaScript
Stelle
10.2k
Fork
4.9k
Merge medio
5g 4h
PR unite (30g)
17

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di npm/cli

Tutte le issue di npm/cli

Issue simili

Altre issue su JavaScript

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.