After the npm Hack: We Need Real Package Management—But We Won’t Do It
The author uses a major npm hack to argue for a radical overhaul of JavaScript’s dependency and package distribution model. He proposes a standard library, consolidation of micro-packages, and distro-style practices like curation, signatures, and reproducible builds, and urges broader ecosystems and corporations to invest in real fixes. Yet he predicts none of this will happen and that the industry will settle for superficial measures and remain vulnerable.
Key Points
- The npm supply-chain breach exposes deep, long-standing flaws in JavaScript’s dependency and distribution model.
- A better future would include a real JavaScript standard library, consolidation of micro-libraries, and a redesigned npm adopting Linux distro practices (curation, signatures, webs of trust, reproducible builds).
- Decoupling development from packaging and empowering maintainers to curate trusted collections would reduce attack surface.
- Other ecosystems (Cargo, PyPI, RubyGems) face the same risks and should change course preemptively.
- The author expects only superficial responses (e.g., mandatory 2FA, token donations) and no meaningful systemic reform.
Sentiment
The Hacker News community is largely skeptical of the article. While most agree supply chain security is a real problem, they find the article's framing outdated (particularly the micro-dependency angle), its proposed solutions impractical at npm's scale, and its nihilistic conclusion more of a rhetorical device than a useful contribution. The community feels the JS ecosystem has been steadily improving and that the article does not engage with that reality.
In Agreement
- The problem is social and structural, not technical — companies will keep choosing the cheapest option, which is doing nothing
- The article does contain concrete suggestions (universal signatures, webs of trust, reproducible builds) that commenters too quickly dismissed as hand-wavy
- Ecosystems like Deno's standard library demonstrate the value of self-contained, well-maintained code over sprawling dependency trees
- The broader point about micro-dependencies as a systemic risk still holds, even if specific examples like left-pad have been addressed at the language level
- A quality certification or inspection system for npm packages would improve the ecosystem, even if applied incrementally to just the most critical packages
Opposed
- The left-pad complaint is outdated — JavaScript already has String.padStart() and the community has moved toward zero-dependency packages
- The distro model simply cannot scale to npm's three million packages, which is orders of magnitude larger than what Linux distributions manage
- The article reads more as a rant than actionable guidance, rehashing known problems without novel solutions
- Practical mitigations are already being implemented, including pnpm and Yarn minimum release age settings and JSR's trust model
- AI/LLM-based package scanning would be counterproductive — it would relax human vigilance and invite adversarial obfuscation techniques