The Everything NPM Package

Original Article ↗ Hacker News Discussion ↗

An experimental “everything” npm package that depends on tens of thousands of other packages exposed a flaw in npm’s unpublishing policy, effectively blocking maintainers from removing their own packages if anything depends on them via a wildcard version. Commenters debate how much blame lies with the package author versus npm’s design choices, especially the handling of `*` versions and the legacy reaction to the left-pad incident. The incident also reignites broader concerns about JavaScript’s micro-dependency culture, weak standard library, and trust in semantic versioning, prompting comparisons to ecosystems like Go, Rust, Maven, and suggestions such as vendoring, better tooling, and stricter norms around dependencies.

NPM “*” Versioning and Unpublish Policy

  • The “*” dependency constraint plus npm’s unpublish rules means a single package that depends on “everything” can effectively prevent authors from unpublishing their own packages.
  • Some call this a “bug”; others say it’s intentional to avoid breaking builds when versions disappear.
  • Suggestions:
    • “Softer” interpretation of * so unpublishing is allowed as long as at least one version remains.
    • Soft deletes / yanking: hide versions from new resolution while still serving them for existing lockfiles.
    • Manual review for unpublish requests or disallow unpublishing entirely except for malware/legal cases.

SemVer, Pinning, and Reliability

  • Debate on how trustworthy SemVer is in the JS ecosystem:
    • Some see frequent accidental breakage and think SemVer is nearly meaningless.
    • Others report that most minor/patch updates work fine; breakages are rare and treated as bugs.
  • Common mitigation: pin exact versions and update manually, using SemVer only as a signal for review intensity.
  • Pinning doesn’t help if a version is unpublished, hence the controversy around unpublish rules.

Responsibility for the “Everything” Package

  • Views range from “irresponsible experiment/trolling” to “legitimate stress test that exposed a flawed npm design.”
  • Many argue the root problem is npm’s policy, not the experiment; some think the author owes a more detailed explanation, others see no need for a stronger apology.

Micro‑Packages, Culture, and Risk

  • Widely criticized: extreme micro-dependencies and over-reliance on trivial packages, which amplify breakage and security risk.
  • Some see this as cultural (“reach for a library for everything”), tied to weak standard libraries and historical browser quirks.
  • Several argue that developers should be more cautious and accept responsibility for the dependencies they add.

Proposed Ecosystem Improvements

  • Stronger, more complete standard libraries to reduce the need for tiny utility packages.
  • Social/quality scoring of packages and dependency graphs, with warnings for explosion in transitive deps.
  • Making reuse “costly enough” (time, review) that developers feel the impact of each new dependency.
  • Vendoring or locking dependencies more aggressively; tools like Go’s module proxy, Cargo’s yanking and vetting are cited as positive models.