My thoughts on writing tiny reusable modules that each do just one thing. These notes were adapted from an email I recently sent.
If some component is reusable enough to be a module then the maintenance gains are really worth the overhead of making a new project with separate tests and docs. Splitting out a reusable component might take 5 or 10 minutes to set up all the package overhead but it’s much easier to test and document a piece that is completely separate from a larger project. When something is easy, you do it more often.
I’ve observed the biggest gains for splitting something out into a separate module when I’m completely stuck mucking around in a larger application. When I isolate the problem down to the scope of a small module, it’s much easier to see how that small piece fits in with the greater application objective.
Another technique is to pick tools and approaches that don’t involve a lot of boilerplate in the first place. My usual flow for writing a new module is:
With practice, I run through all these steps very quickly now. Not all of these are strictly necessary and sometimes I’ll skip a step but this is mostly the procedure I use for new modules.
As much as possible, I try to build large-scale projects using lots of tiny modules so I just repeat this process whenever I need some reusable component that doesn’t yet exist in quite the form I need it to exist. As more modules are published to npm I expect I won’t need to write so many modules but there will always be room for new stuff.
When applications are done well, they are just the really application-specific, brackish residue that can’t be so easily abstracted away. All the nice, reusable components sublimate away onto github and npm where everybody can collaborate to advance the commons.