npm Packaging Part 1: Thinking About Publishing A Package?

This is the first installment in a series exploring publishing npm packages. The goal is to walk through publishing everything from a simple, dozen-or-so lined node module to a relatively complicated react component library with typescript & flow definition files and pretty import paths.

npm has been around since 2010, allowing JS engineers to publish javascript modules for distribution. As the default package installer for Node.js it received adoption as node grew in popularity, and with more recent javascript tooling has allowed for the explosion of JS as one of the most far reaching programming languages.

Why do packages exist?

The simple answer is distribution.

A package has some distinct advantages to copy-paste solutions: ease of import (using a unique name, version), an explicit api interface, and most importantly code isolation. This allows a package to be used broadly as small components in larger applications, minimizing the need to re-solve problems (like date-time management) or providing abstracted, simplified interfaces to more complicated low-level apis (like DOM manipulation, e.g., react).

Their ease of distribution is enabled by npm’s hosted registry ( and the accompanying command-line program npm, which can take in a unique name and install all the required pieces to get that code running in your app. I’ll also note, npm isn’t the only choice: yarn, which was released by facebook a few years ago, and other package installers like npmdnpm-install and ied, offer some optimizations and alternatives.

As of this writing there are nearly 900,000 packages on the npm registry that were downloaded more than 9,000,000,000+ times in the last week. With those kinds of numbers there is likely a solution to whatever problem you’re having; if not, several solutions. And that’s just fine, having more choice is good. And this system is what has made the internet the world-connecting and problem-solving platform it is.

Do we really need more npm packages?

A fair question: like I said above, there’s hundreds of thousands of packages solving any number of problems. What makes your solution unique? Honestly, it doesn’t need to be: having all that choice is good.

Don’t worry about whether you are solving anyone’s problem but your own, because if you’ve solved a unique problem you encountered in the construction of whatever you’re building, it’s probably worthwhile to share your solution. Some incredibly simple packages can be so small but useful they wind up being used by virtually everyone, and there’s a fun story about how a small (11 line function) package named leftpad became so ubiquitous that it broke the internet.

What makes a good npm package?

Simply put, usefulness.

npm exists to allow packages of code to be distributed and consumed easily. If a problem you have solved is solvable in isolation, it can be turned into a package and re-used by others encountering the same or similar problems.