i have been watching left-pad-gate unfold with rapt attention

i will not comment on module scope, or the depth of dependency trees, because it seems to be philosophical. 1

but, i do have a lot of thoughts and feels

  1. left-pad didn't break babel because babel had deep dependency trees, or small modules, but because npm has mutable addresses to packages. left-pad was simply removed, so the package manger could not find it, and there was no reasonable equivalent to Internet archive for npm at that time.

yes, left-pad was a small module. yes, many npm modules are small. and, yes more dependencies does mean a higher chance that one of them will break.

but, why is that really? deep trees and many packages intrinsically? or the fact that our package manager can upgrade these packages without asking us, or lose packages altogether?

one old idea is, why not a content-addressed package manager? gx is a promising project that delivers packages over ipfs. it's semantically versioned, and, because it's content-addressed, you get shrinkwrapping for free! several of us hang out on #gx on freenode, and gx-js is trying to make this approach practical for the node/js community

  1. npm packages are unsigned. i know, sounds like something npdoty would say, but consider this: if someone takes down their package, someone else can upload a new one with bad stuff in it, and everyone's package manager will pull down this other person's version on npm install.

clearly, this is super bad news, bears. the current system has worked so far, mostly because the opensource/libre community is super nice. but, npm publishers may not always be so benign, especially now that more companies use npm. 2

signing packages is another way to help save us from package shenanigans - and authors need not be the only parties who sign. if i trust a key that signed a package, that's good enough for me - it's almost like getting a star on github, but cryptographically secured, and lends itself well to building recommender systems on top. this is really my big ax to grind, and gx-js only solves a small piece of what i see as a much larger idea about how software should be published, discovered and distributed

ok, i promised i wouldn't touch on the philosophical issues around module style, and i will hold good on that promise, but i do want to put in a slight justification for why so many npm modules are small

  1. module chaos happens because js developers don't trust standard language features. we have is-positive-integer because javascript has no reasonable types, only 'number'. yes, it's a string, yes it's in single quotes. this is the shit we put up with - we all put up with - when we want to write a program that runs in a web browser.

polyfills are a part of life. for gods sake, we assume we need a polyfill for stuff like reduce, because we have grown to mistrust the language and its interpreters, from experience. we use small modules because this approach makes us more productive in the overwhelming majority of cases.

here's a more sane example: getusermedia. it explains in the readme why you want this module.

currently, there are several efforts that try to extend and polyfill core language features in hopes of flattening developers' dependency trees. there are non-tiny, library-of-babel-type libs like google closure library and lodash, or respectable transpiled languages that make js seem reasonable (like scala.js and clojurescript - i've had great experiences with the latter).

then there are tiny modules and polyfills, which are easy to learn (often they expose a single API), easy to test, easy to swap in and out. i say, with content-addressed package management, this approach would be ok. but, i am no dogmatist in any case. my modules are small, but i have also contributed to kefir, a relative monolith no dependencies.



background: i have published packages on npm, a few of which are used by people. i learned almost everything i know from substack, who started a js study group at sudo room that happens every thursday, free of charge - an incredible resource to the east bay.


the worst thing i know, someone was uploading King of the Hill episodes to npm (an apocraphyl story from substack). not a bad idea - definitely easier than an ftp or torrents - but ipfs is even easier. you can stream movies! and you don't have to worry about DMCA takedowns!