Yesterday two things happened in #mediagoblin:

• One community member remarked in surprise that npm was listed as a requirement in MediaGoblin's documentation since the 0.8.0 release. Surprising indeed! This is because of the attempt to remove our committing of javascript libraries into MediaGoblin's extlib directory. The real goal of this was twofold: towards better practice so that upgrading javascript/css/etc dependencies was easier (we are using Bower on top of NPM), and to make packaging in distros easier (by avoiding leaving places where browser-client-side dependencies can be symlink'ed in rather than bundling these things ourselves).
• The second thing that happened was I expressed in frustration how much I dislike NPM, towards which a friend in the channel exclaimed surprise. NPM is their favorite language package manager, how could I dislike it?

The irony that binds the former and the latter together is, despite our usage of NPM/Bower to simplify deployment, anything that uses NPM as a package manager can probably never be packaged by distros. This was the crux of my blogpost "Let's Package jQuery: A Javascript Packaging Dystopian Novella": because each dependency bundles its own dependencies, you end up with each dependency having its own versions of dependencies, and aside from being a bloated nightmare in its own way, you may have two versions of say uglify-js which are totally incompatible, and both of these are running side by side. This is a serious problem for several reasons:

• On a traditional distribution like Debian or Fedora, this is an impossible situation, since traditional distributions cannot easily accomodate multiple versions of the same package.
• Even in fancy-pants new-age functional distros like NixOS or GuixSD where such a thing is possible, managing that dependency chain is mind-bendingly complex, and almost nobody is going to want to do it.
• The culture of npm is to break things down into many super tiny packages, which is fine in npm-land, but exhaustingly complex for those trying to package free software distributions.
• This also introduces potentially serious security issues: even if you are using all the latest versions of your dependencies, your dependencies' dependencies may be massively out of date, and it's hard to keep track of that. You may be presenting your users with dangerous security vulnerabilities and may never notice.

Despite all this, npm is popular with many of its end users. It's easy to understand why: the decisions made above make it very easy to get up and running with npm, though not necessarily easy to maintain keeping things up to date in the long run, and when pushing out deployments while eschewing the system package manager, things appear to "just work". And if you're working for a startup which is using NPM for its proprietary "top level product" which only goes out to its own personal sever deployments, maybe this doesn't matter.

For those of us concerned with building applications we want to push to end users for advancing network freedom though, this might be a serious problem.

(The similarity to this problem to "application-container systems as static compiling on a distro-sized level" is left as an exercise for the reader!)