In the last month, we’ve alluded to the relationship between package managers and small, modular packages on a couple of occasions, without explicitly diving in to what that relationship looks like.
Modularity and the NPM ecosystem
I’ve written before about the trend towards granular software packaging and what that means for developing and shipping software: smaller packages are designed for simpler tasks, and tend to be updated more frequently. But does this paradigm hold true in the NPM ecosystem?
However, there are downsides to this modular world: it’s more difficult to wrangle and distribute the proper packages, and the reality is that there is a mostly forgotten and unused tail of open source.
It’s generally accepted that usage of open source has a long tail, meaning that a small number of packages account for most usage, and most packages receive little activity (following the Pareto principle).
This doesn’t necessarily mean that these packages are ignored by end users—many of whom host their code privately, where usage isn’t publicly visible—but it does make managing and distributing all this software more cumbersome.
Package managers such as NPM exist to try to alleviate that difficulty, but they primarily help with the distribution and installation process. Once a user is running tens or hundreds or thousands of such granular packages, a new challenge is born: keeping track of rapid changes and updates to all of your open source dependencies.