My First npm Publish

This is the story of a boring client-side JavaScript module I wrote five years ago that became my first npm publish and is now the architectural base for the most useful modules I’ve ever written.

I sensed something was wrong but couldn’t put my finger on it. Everything I’d written for the single page app I was building worked as expected, but I couldn’t shake that weird feeling.

Something was seriously wrong though. Adding new features was getting progressively more complex. What started off as independent UI components were getting increasingly interdependent. Pressing play didn’t just start playing a track anymore. It opened up the Track Detail Panel, added the cover art of the track to the Session Listen History Bar and highlighted the track on the Track Listing component. That play method kept getting bigger and the different states each component could be in when play was pressed exponentially increased complexity.

I can’t remember how I’d stumbled on a very long post about patterns or why I was generally unimpressed by Singletons, Factories and all the other patterns it talked about so far, but my brain and soul felt like it was struck by lightning when I started reading about the Publish Subscribe pattern.

It made perfect sense! Instead of a fat play method that had to be aware of the state of a number of components, I could simply publish a “play-track” event containing the track id, and subscribed components look at their own state and act accordingly. If a component was disabled, it simply removed its subscription to the “play-track” event. Adding a new component is simple too: make the component subscribe to relevant events and manage its own details. Extending components is just a matter of publishing events and getting other components to listen to it. I didn’t even bother reading the remaining patterns; Publish Subscribe was the hero I needed.

I wrote a really simple implementation, added logging so I could see what was going on, played with it and started implementing it into the project. The significantly reduced time it took to build and properly integrate new components made up for the time spent re-engineering the components to use the pattern. Features were flowing straight from my brain to my finger-tips and keeping everything working correctly was so easy.

As I wrote more JS, I found myself repeatedly reaching for the Publish Subscribe pattern so when I started getting into Node.js, naturally I brought my trusty pubsub with me. On November 24, 2014, I published it to npm!

Spent a lot of time trying to write reasons why you should use it. Funny, because as far as I know I’m still the only person to ever use it.

It’s the foundation of two other modules I’ve written that are essential to my adventures in Node.js. One is a simple flow control library, the other is a process supervision library that also allows a supervisor (or any process it is supervising) to send mail to each other.

My first npm publish is simple, boring and obscure, but I use it every time I write JS. I’ve learned so much about the language and the value of loosely-coupled architecture because of it. Been meaning to write a little bit about this innocuous library that has made me a much better JS developer for a while, so I’m really grateful for npm’s #myfirstpublish campaign giving me a good reason to finally do it 🙂

Get New Posts via Email

I don't always post, but when I do, you can get it sent directly to your inbox.

Join 10 other subscribers