That is a good question, I think that modularity which we are talking about and using nowadays is going too far, just take a look at num-lines, num-lines dependencies and this.

People are now depending on a bunch of "packages" just to write a simple application, it's becoming ridiculous.

David Hanyes brings some good points on his post "NPM & left-pad: Have We Forgotten How To Program?":

NPM ecosystem participants have created a fetish for micro-packages. Rather than write any functions or code, it seems that they prefer to depend on something that someone else has written.

Yes, I do think we should put a limit to it since it's becoming normal to use a simple function as a dependency package, just think about the num-lines package, you want to explode() (PHP background :P) your strings in \n and \r\n, you will end up adding 9 files + 10 files from its dependency, is it really worth it?

Pretty much everything is a double edge sword, in almost every aspect of life :)

Unsolicited wisdom aside, for sure it served as a reminder to be careful when depending on other packages. Modularity has not jumped from being the holy grail to being the root of all evil, but now you know you have to think twice before adding dependencies on everything just because you can.

I haven't used one of those yet, but I'd think that private npm registries are an option to safeguard yourself against losing dependencies. Like Claudio below said: The issue showed everyone that there is a risk to the "make everything a package" approach. Now we know it, we'll watch out for it, put mitigations in place, and move on.

Modularity as a code design idea is still immensely advantageous (readability, testability, scalability, velocity of deployment etc etc). It's just not perfect and needs caution.