i have been watching left-pad-gate unfold with rapt attention
but, i do have a lot of thoughts and feels
- 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
- 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
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
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.