While working on Supercomments, I regularly came across third-party Node.js packages whose version in the npm registry was not the one I wanted. In most cases this was because the maintainer hadn't updated the version for a while, although in at least one instance it was because the code I needed was so bleeding edge that it hadn't made it into the mainline branch of the project repo yet.

Luckily, npm has stupendous support for using code directly from a GitHub repository. Just put the name of the GitHub repo into your package.json dependencies instead of the version range, and it will be pulled from GitHub, stripped of unnecessary files using .npmignore and built (if necessary) using its install script. You can even specify that a particular branch, tag or commit should be pulled using the org/repo#commit syntax.

This got me thinking: why do we need npm registry anyway? Everything is hosted in GitHub nowadays, so updating the registry is just one extra thing for project maintainers to feel guilty about neglecting. Mind you, there are a few reasonable arguments for keeping npm registry:

• Repo size. npm strips unneeded files from the repo, but you still have to pull the whole thing. In the npm registry the unneeded files are already removed. But in a world of ever-increasing storage and bandwidth, a more convenient solution always wins out over a more efficient one, right?
• Distributing load. "Do we want GitHub to be the single point of failure for the entire software development world?", you may be asking. However we answer that question, the truth is that it already is. Considering the scale and budget available to them, I'd trust the ops people at GitHub a darn sight more than their npm registry equivalents to keep the lights on and the bytes flowing. GitHub does get DDoS'ed occasionally, of course, but we'd arguably be better off investing in a few read-only GitHub mirrors for Node.js package repos instead of a fully-fledged registry.
• Semantic versioning. package.json supports semantic versioning, so you can use those ~ and ^ prefixes that you always get mixed up (quick: which is which!?). In my experience, you generally end up shrink-wrapping your dependencies anyway, in which case you can tie the GitHub dependencies to a specific commit. A lot of other cases can be handled by using a specific branch or tag. The marginal advantages of version ranges and ~/^ wizardry probably aren't worth the hassle.

My conclusion: we're using npm registry out of habit, not necessity. We'd be better off abandoning the whole effort and concentrating on making GitHub a better registry by supporting things like commit ranges and the read-only mirrors mentioned above.