'everything' blocks devs from removing their own NPM packages

Original Article ↗ Hacker News Discussion ↗

A prank “everything” package on the npm registry recently declared dependencies on virtually all other packages, exploiting a policy designed after the infamous left-pad incident that prevents unpublishing modules with dependents. This effectively blocks maintainers from deleting their own packages and has reignited debate over how registries should handle deletions, yanking, and long-term availability of code. Commenters contrast npm’s design with alternatives like Cargo, PyPI, and Maven, and broaden the conversation to the complexity of package management, ecosystem reliability, and whether developers should vendor dependencies instead of trusting public registries.

NPM “everything” package and policy clash

  • “Everything” depends on (almost) all other NPM packages, triggering NPM’s rule that packages with dependents cannot be unpublished.
  • Commenters note this rule was introduced after the left-pad incident to protect ecosystem reliability.
  • Result: authors of any depended-on package effectively lose the ability to delete it, which some see as NPM wanting “to have its cake and eat it too.”

Should packages be deletable?

  • Some argue deletion should be impossible once published; registries should have perpetual distribution rights.
  • Others want softer mechanisms:
    • “Yanking”/soft-delete (like Cargo, NuGet, PyPI) so old lockfiles still work but new resolutions avoid bad versions.
    • Deprecation flags, hiding in UI, or clear warnings instead of hard removes.
  • Use cases for deletion: serious bugs, deprecation, or accidental publication of sensitive or embarrassing content.
  • Counterpoint: sensitive data is already exposed once uploaded; proper fix is rotating secrets, not deletion.

Mitigation ideas for this specific issue

  • Hard limits on dependency tree size (e.g., based on real-world P99, with exceptions) are proposed.
  • Others point out this doesn’t fully help: attacker can just use many small “chunk” packages.
  • Several think the real fix is revisiting NPM’s yank/unpublish policy, not dependency limits.
  • Some downplay the impact as a mild inconvenience; others see it as a clear systemic failure.

Broader package management and ecosystem debates

  • Comparisons with PyPI, Rust’s Cargo, Maven, NuGet, CPAN, Hackage, Nix, Bazel, Go modules.
  • Many highlight that malicious or problematic packages exist across ecosystems; NPM is not unique, but its scale and history make issues more visible.
  • Debate over a universal, language-agnostic package manager:
    • Proponents: dependency specification and file delivery are generic problems.
    • Opponents: deep coupling to language semantics, build systems, semver behavior, and security models makes unification unrealistic.
  • Strong criticism of the JS/NPM ecosystem as chaotic and “unserious,” driven by low entry barriers, tiny packages, and deep dependency graphs.
  • Others defend NPM as fundamentally good but overwhelmed by popularity and legacy design choices.