Micro-libraries should never be used

Original Article ↗ Hacker News Discussion ↗

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.