It has long been a fantasy of mine to write about node modules. Something about NodeJs appeals to the writer (or the developer) in me. It could be I’m intrigued by many developers moving towards NodeJs and abandoning all else; it could be that some developers will have nothing whatsoever do with it; or it could be something completely different, something that I can’t quite put my finger on. Either way, the topic appeals to me as a “hot topic”. I have worked with NodeJs for some years now, and while my knowledge of, and experience with it are probably not enough to be dangerous, they are certainly enough to say a word or two about it. I shall limit myself to node modules as much as I can, for over time I have come to appreciate that many times one either loves them or hates them passionately.
Arguably, the most outstanding thing about the node package registry is that you can find almost any package there. It is quite like a pocketknife. You want a package to handle dates with as few lines of code as possible? Here, check this out and please go your way. What, no? You don’t like it? Try this one instead, but beware the maintainer passed away seven years ago. In a word, the registry is a world of its own. It is the gift that keeps on giving. Certainly this is a good thing? For some packages there are quite handy. I do not want to go down the long, winded road of developing an API from scratch when I can go by the Express way. Neither do I want to sit hours parsing dates when I can do it in a Moment.
Something else that I didn’t like, and that is putting it nicely, is the dependencies of the packages in the node package registry. Dependency resolution has since been improved, but there was once a time when you’d happily run npm install, and if you set your coffee too hard on the table the whole thing would fall apart. That is of course an exaggeration. Yet many times when picking up an existing project, one of the trickiest hurdles would be installing dependencies, so that you’d be hamstrung even before you really started. One version of a dependency would change and all packages depending on it would be practically useless. A maintainer of a package is technically free to change a package as he sees fit. He could even stop maintaining it and be under no obligation to tell its users. Yet we happily bind ourselves to these packages and hope for the best.
The large amounts of space occupied by node modules has been a favorite spot of attack by people who will not work with Node. A meme goes that the only thing heavier than Thor’s hammer is node modules. Myself, I occasionally delete node_modules folders when my computer runs out of disk space and the result is simply amazing. I feel my computer breathing freely again.
Uncle Bob (Robert C. Martin) relates in his blog article, Framework Bound[2], that (most?) framework authors create frameworks to solve their problems. The frameworks are useful in as much as our problems overlap with the problems those frameworks were created to solve. Beyond that, the frameworks are potentially derailing. For sometimes when a framework changes, we must change our code to adapt. We become puppets that can be yanked this way and that way or be left to collapse on the floor. The tiniest update to a framework can bring everything to a grinding halt. I think the same thing can be said about packages.
When used judiciously, the packages in the node registry speed up development. Computer memory is cheap and there are clever compression and tree shaking algorithms that come to our aid. That a package exists to check if a number is odd does not mean we should use it. That said, extremely useful packages do exist. Very generous people put their time into creating such handy products and provide them for free. Surely the least we could do is not throw away the baby with the bathwater. One will also please to remember that it is a poor workman who quarrels with his tools.
