In defense of small packages.
By Peter Chapman
When I first started web development, I used to stick my nose in the air at people who would just import a ton of packages for tasks that I deemed easy to write, and thus not worth the import.
My reasoning was two-fold:
- It helped to hone your craft. Learning how the soup is made when it came to simple utility functions made you a better programmer.
- Reducing the number of dependencies in turn reduced your bundle size.
I still feel both of these reasons have valid cases, but as time has gone on, and I have less of it, I’ve learned the value of producing meaningful results. How much time have I spent writing the same simple validation logic? Or writing utility functions around boolean state? It may only be 5 minutes here or there, but that time adds up.
In order not to compromise my ideals while still leveraging the work I’ve done in the past, I’ve started building a collection of private npm packages. Any time I reference code from past projects, or copy and paste the same bit multiple times, I break it into its own package. This allows me to take known working code, add test coverage if needed, and reuse it easily. I’m still solving these problems myself and am able to scope the dependencies to packages I’d already be importing, like React or Ramda.
You won’t see me importing packages like leftpad anytime soon, however, I’ve come around to the idea of using npm like Lego blocks to leverage solutions to past problems in order to allow me to move faster on larger scale problems.

Author's Note:
Leaving this old post here for posterity. It could probably be better written, and I might revisit it in the future. For those working in startups, freelancing, or engaged in numerous side projects, creating your own 'Batman-style' utility belt of easily reusable code can be incredibly beneficial.
