70% of new NPM packages in last 6 months were spam

Original Article ↗ Hacker News Discussion ↗

A surge of spam on the npm package registry—driven largely by crypto-style incentives from the Tea protocol—has resulted in estimates that around 70% of new packages in the past six months are low-quality or malicious. Commenters highlight how easy it is to spoof dependencies via `package.json` and lockfiles, criticize npm’s weak validation and confusing UI, and worry about the broader security and supply-chain implications for organizations that pull in hundreds of transitive dependencies. There is also concern that this garbage content will pollute AI training data and further degrade trust in an ecosystem already seen by many as fragile and poorly governed.

NPM Dependency Spoofing & Tooling Issues

  • The npm website treats any dependencies key whose name matches a package as if it depended on that package, even when the value is a URL or GitHub shorthand pointing elsewhere.
  • This makes the UI show and link to the “wrong” package, hiding that the actual dependency is a different tarball/repo. Several commenters see this as a serious security bug, not just confusing UX.
  • package.json allows URLs, git, and GitHub shortcuts as versions, so spoofing is standards-compliant but misleading.
  • package-lock.json can also be manipulated; npm relies on the lockfile and doesn’t enforce strict consistency with package.json.
  • npm ci improves lockfile integrity but still doesn’t verify on-disk node_modules. Some want a “verify installed tree” command, similar to other ecosystems.

Tea Protocol Incentives and Spam Explosion

  • Tea’s crypto-based reward model pays out based on package metrics, incentivizing mass publication of nonsense packages and circular dependences/stars.
  • Many call its tokenomics a textbook cobra effect / Goodhart’s law: once a metric is tied to money, it’s gamed and stops measuring quality.
  • Some argue Tea is not genuinely “remediating” the problem and label it as a grift.

What To Do About Spam and Unpublishing

  • Proposals: bulk-remove or ban packages with tea.yaml, or ban Tea-related spam accounts.
  • Pushback: mass unpublishing would violate npm’s own unpublish principles and undermine expectations of immutability and stability.
  • Others counter that terms already allow removing abusive or squatting content and that rigid adherence to principles can harm ecosystem health.
  • Debate over whether leaving spam accounts visible helps correlation or just pollutes search; “broken windows theory” is invoked.

Ecosystem Culture and Comparisons

  • Many see npm/JS as uniquely prone to millions of tiny, low-quality packages and dependency bloat; some blame language culture, junior-heavy community, and small standard library.
  • Others argue every popular ecosystem (Python, Rust, etc.) has supply-chain issues; JS is just larger and more visible.
  • Go is cited as a contrasting culture where importing third-party code (beyond stdlib) is relatively rare.

Security, Supply Chain, and Trust

  • People are uneasy about pipelines pulling hundreds of transitive packages with limited review.
  • Some note prior measures: provenance verification for packages built via specific CI, and mandatory 2FA for “high impact” packages.
  • There is interest in a separate, curated “secure registry” with audits for long-term, enterprise use.

AI Training and Data Pollution

  • Concern: spam packages pollute training data for code models, reinforcing “garbage in, garbage out.”
  • Counterpoint: modern systems already rely heavily on filtering and spam detection; high-quality curation at npm scale is still very hard.
  • Disagreement over how much poisoned code data would actually increase LLM “hallucinations,” and how feasible large-scale dataset filtering really is.