If NPM would have prevented the depublishing, he would have made a scene and in the worst case, they would have looked bad.
How they actually handled it, the library author got full freedom but also full responsibility
If NPM would have prevented the depublishing, he would have made a scene and in the worst case, they would have looked bad.
How they actually handled it, the library author got full freedom but also full responsibility
Lesson: Vendor your dependencies, I guess. Although a lot of the ire around left-pad was programmers using a library for something so trivial, but that's a different conversation.
Very true.
Although, from 2012 onwards, up to around the time of the leftpad incident, the trend - and the pressure - was to minimise the amount of work your code was doing and to publish tiny packages that only did one thing or solved one problem, deferring to other tiny packages for anything non-core. I remember colleagues more embedded in the JS world than I was passionately arguing for this in 2012/13.
And it did make some sense: bandwidth matters, particularly on mobile devices (which became a key source of traffic during that period) so why pull in some gigantic do everything library when you only need a handful of functions[0]? Sure, minifying and pruning help but, due to JS's nature, pruning can only get you so far.
But, yes, I think leftpad was something of a teaching moment on the downsides of this approach.
[0] Of course, if you then stick 6 different tracking scripts in all your pages, it's super-easy to undo all the good you've done by minimising your bundle size, but that's a different conversation.
I mean he says he asked them to remove all his packages, expecting them to do so gradually, following whatever mitigation strategy they felt appropriate (e.g. some kind of warning and fadeout process), and instead they gave him a script to do it immediately so he did that.
As opposed to looking much worse? Easy decision.