Micro-libraries should never be used

Original Article ↗ Hacker News Discussion ↗

Micro-libraries in JavaScript—tiny packages that often wrap just a few lines of code like `left-pad` or `is-number`—are criticized for creating fragile dependency chains, security risks, and unnecessary maintenance overhead. Commenters contrast this with richer standard libraries in other languages, arguing that JS’s barren stdlib and browser compatibility concerns have fostered a culture of over-reliance on trivial packages. Alternatives proposed include vendoring small utilities directly into codebases, building internal or curated shared libraries, or expanding the official standard library to cover common needs.

Standard Library vs Micro-libraries

  • Many argue JS/Node’s weak or “barren” standard library is the root cause of micro-libraries like left-pad and is-number; in other languages these are just stdlib functions.
  • Some suggest multiple “layers” of standard libraries or curated meta-packages, analogous to coreutils or batteries-included languages.
  • Others counter that putting too much in the stdlib freezes bad designs and creates a graveyard of legacy APIs; a minimal stdlib plus “free-market” libraries is seen as healthier by some.

Perceived Benefits of Micro-libraries

  • Modularity and composability; “do one thing well” is compared to Unix and Forth philosophy.
  • Shared maintenance and bug-fixing effort across projects; more eyes on code and potential for plugins.
  • Portability and semi-standardization: teams can rely on common helpers across codebases.
  • Some are effectively “finished” and change rarely, reducing churn.

Critiques and Risks

  • Massive dependency trees: many tiny packages plus their own dependencies lead to bloat, attack surface, and incidents like left-pad.
  • Hard to audit and manage 100 micro-deps vs a few larger, well-curated libraries; supply-chain attacks become easier.
  • Semantics often don’t match local needs (e.g., what counts as a “number”); you inherit someone else’s definition and edge cases.
  • Over-reliance is seen by some as a substitute for language competence or as fear-driven (“I might miss an edge case”).

Dependency Management Strategies

  • Suggested alternatives: copy-paste trivial code (respecting licenses), maintain internal utility libraries, or vendor dependencies.
  • Others prefer forking small libs and using them as submodules, occasionally pulling upstream changes.
  • Lockfiles, internal mirrors, and strict pinning are highlighted as mitigations against registry or unpublish issues.
  • Some advocate LLMs to generate trivial helpers instead of adding micro-dependencies.

JavaScript / NPM Ecosystem Factors

  • Frontend JS “physics” (download size, diverse browsers, historical quirks) and weak typing are seen as drivers of paranoia and tiny helper reuse.
  • Culture and tooling (easy npm publish, low barriers) encourage proliferation of one-liner packages.

Debates on Size, Scope, and Unix Analogy

  • No consensus on what “micro-library” means (lines of code? single function?); this makes “just copy-paste” advice risky.
  • Disagreement over Unix analogy: some see coreutils-like tools as precedent for small composable units; others note they ship as a coherent, curated bundle, unlike random npm microlibs.