Please Stop With MicroLibraries NPM

Micro-libraries—tiny, single-purpose npm packages—should be avoided because every added dependency multiplies failure points across security, compatibility, performance, and maintenance. The left-pad incident from 2006 is the cautionary tale: a trivial package that trimmed strings became a system-wide outage when it was removed after a dispute, breaking thousands of downstream projects and even taking major services offline. That history matters because it reframes “small utilities” as supply-chain and operational risks, not harmless convenience.

The core argument goes further than “don’t use dependencies.” It lays out a framework for weighing libraries’ costs and benefits and claims the balance often tilts negative for micro-libraries. Benefits are real—libraries can save development time, provide more robust implementations, and deliver ongoing security and bug fixes maintained by others. But those upsides depend on the library being a good fit, mature, widely used, and stable under upgrades. Costs start immediately: a dependency can be a poor match, force awkward adaptations, introduce bugs or bad APIs, and trap teams in abstractions that make upgrades painful. Even when code is correct, updates are unpredictable—breaking changes, deprecated functions, performance regressions, and bundle-size growth can arrive without warning.

A major theme is that dependency risk is not limited to the direct package. Transitive dependencies quietly expand the attack surface and inflate the project footprint. In JavaScript ecosystems, node_modules bloat is common: routine updates can multiply storage and download sizes, increasing install times, build times, and user bundle sizes. The discussion points to initiatives aimed at cleaning up dependency sprawl, but also notes that even cleanup efforts can be undermined by the same heavy dependency patterns.

Security concerns are treated as supply-chain realities. Installing packages can execute scripts during npm install, and every dependency is a potential vector for malicious or compromised code. Vendoring can reduce exposure to future installs, but it doesn’t eliminate the need to vet and re-vet when updates happen. The transcript also highlights how version ranges and tooling behavior can lead to unexpected upgrades, meaning teams may not fully control what code ends up in production.

To make the case concrete, the transcript dissects the npm package “is-number,” a micro-library that checks whether a value is a finite number or a finite non-empty numeric string. The analysis argues it provides little practical value over straightforward, easily verified code, and it introduces definitional ambiguity—some users consider numeric strings “numbers,” others don’t. Once multiple major versions appear, semantic versioning assumptions break down in practice, and duplicate implementations become a discoverability and maintenance problem.

The closing message shifts from risk management to developer capability: libraries are not magic, and fear of bugs or edge cases often drives people to outsource simple logic. The transcript encourages writing small pieces of code directly—sometimes even copy-pasting from sources like Stack Overflow—because debugging and understanding one’s own code is easier than treating third-party utilities as black boxes. The overall takeaway is that micro-libraries trade away control for convenience, and the convenience rarely justifies the compounded cost.