NPM packages: they ain’t free, you know


A lot of packages will save you time, no doubt about it. But you need to make some attempt to quantify that.


If you don’t want to be the best damn JavaScript developer you can be, then you can skip this section.


If you’re using someone’s npm package without even looking at their open github issues**, you’re crazy. You want some foxes?

The learning curve

I wrote a post recently about using icons in React. The end result was a component that took an icon name and returned an SVG icon. Pretty simple stuff. In the comments, someone asked why I wouldn’t use a particular icon library. I looked at the library: it used a higher order component and React’s context to be able to color the icon. If you jumped into a code base that used this, you would need to go and read their readme to see how to color an icon. Whereas if you just write the code yourself, it will be clearer how it works because there won’t be any black-box code that requires docs. Not a big deal, but multiply it by 50 packages each with their own vocabulary and you start to feel the pain.

So… what do I suggest?

As you’re next typing npm install…, stop to think about the total cost of that package, over the lifespan of your project. For you and for your fellow developers. Spend a few minutes to compare that to how much effort it will save you today and maybe, just maybe, that the package is a freebie you can live without.



I like web stuff.

Love podcasts or audiobooks? Learn on the go with our new app.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store