An Illustration of Javascript Dependency Hell using left-pad

In the JavaScript ecosystem, it's part of the culture to enthusiastically re-use existing packages made by others as part of one's own work, rather than reinventing the wheel. This means that, on average, an npm package has several production dependencies, as well as several build/test (dev-)dependencies. For a big application or a framework this can result in pulling a big number of direct dependencies, which in turn have their own dependencies, and so on, forming an unexpectedly deep and wide dependency tree, that someone has to manage (FOSS Compliance, security flaw management, ...) left-pad (1) is an npm package with a payload of 11 lines of JavaScript code. When it was unexpectedly unpublished from npm in 2016, the result was described as ""having broken the internet" (2). Leftpad has no runtime dependencies and a few dev-dependencies. However many important packages depended on it, directly or not, and got broken when it disappeared.. 

As a thought experiment, we'll scope the fictive task of re-building and testing left-pad from scratch, including all its recursive runtime and test dependencies, using only dependent packages that we have built and tested from scratch all the way down the dependency tree. How big of an effort would that be?  Would we need to re-build e.g. 10, 100 or maybe 10000 packages or more, before we can finally make and test our very own left-pad package, using no npm package built by someone else? 
Come see this talk and find out!
1. https://www.npmjs.com/package/left-pad
2. https://qz.com/646467/how-one-programmer-broke-the-internet-by-deleting-a-tiny-piece-of-code/