Its interesting how everyone used this as a chance to attack the small modules approach. This approach definitely has downsides, but the problem caused by leftPad being unpublished wasn't one of them.
If jdalton declared a jihad on arrays tomorrow and decided to pull all array related functions from lodash, we would have the exact same problem.
If kriskowal decided that Q must mirror built in Promise and published a version that does this tomorrow, we would again have the exact same problem.
There is only one connection between this problem and the small module approach. As the size of a module decreases, the number of dependencies increases and so does the number of authors that produced your dependencies. With the number of authors increasing, the chances that some author decides to go rouge or protest for some reason also significantly increases.
Therefore, its irresponsible to use this approach with a package manager that allows an old, established module with many dependents to be unpublished so easily by the original author.
Would people automatically update to the new versions of the libraries you mentioned?
The problem with unpublishing is that it changes an existing version. If instead of depublishing a correctly versioned empty module named leftpad was pushed to npm (increment major, because a non-implementation is incompatible with an implementation), there would not be half as much pain.
As long as unpublishing exists, micromodules increase the "attack surface" to this specific method of changing the contents of a specific published version.
If jdalton declared a jihad on arrays tomorrow and decided to pull all array related functions from lodash, we would have the exact same problem.
If kriskowal decided that Q must mirror built in Promise and published a version that does this tomorrow, we would again have the exact same problem.
There is only one connection between this problem and the small module approach. As the size of a module decreases, the number of dependencies increases and so does the number of authors that produced your dependencies. With the number of authors increasing, the chances that some author decides to go rouge or protest for some reason also significantly increases.
Therefore, its irresponsible to use this approach with a package manager that allows an old, established module with many dependents to be unpublished so easily by the original author.