In Defense of Hyper Modular JavaScript
Mike Groseclose

I feel like package gate sucked and we learned some valuable lessons from it with regard to dependencies. I don’t feel like it should be a forum for package size, lines of code, etc. It has been my opinion that a NPM package is a shared abstraction. With that definition, I feel like discerning when to break it out becomes more obvious.

My rule of thumb when I am deciding what should be a module and what should remain locally:

  1. Make sure my utility libraries (lodash, hoek, etc) do not include functionality already.
  2. Quickly scour npm to ensure someone hasn’t already built it. If the package has no tests I don’t use it.
  3. Create locally the utility or node module (So I don’t prematurely optimize, and I can flesh out implementation without needing to publish)
  4. When I encounter the need in another project to use the same functionality I break it out with tests, and publish it.
  5. I refactor the old code

It’s pretty clear the community supports this paradigm(, and I’m glad they do. It’s what makes Node + NPM = Fawesome! I do also recognize that anemic packages arise out of premature optimization. It’s the reason why I feel like software engineering is an art. There is a gut-feeling/fine-line as to when to perform such optimizations.

Like what you read? Give Tyler Garlick a round of applause.

From a quick cheer to a standing ovation, clap to show how much you enjoyed this story.