shrinkpack VS event-stream

It's https://github.com/JamieMason/shrinkpack

Using a lockfile and checking in your dependency tarballs [1] can help insulate you from these problems until you're ready to face them.

I created shrinkpack before left-pad and thankfully it meant that we were unaffected.

A lot of developers, understandably, baulk at checking in dependencies, but there is a concrete benefit in being able to continue uninterrupted during outages.

[1] https://github.com/JamieMason/shrinkpack

Checking in your dependencies with https://github.com/JamieMason/shrinkpack can help insulate you from these problems until you're ready to face them. I created this before left-pad and thankfully meant that we were unaffected.

A lot of developers, understandably, baulk at checking in dependencies, but there is a concrete benefit in being able to continue uninterrupted during outages.

Another possible outcome of "I gave commit rights to someone I didn't know": https://github.com/dominictarr/event-stream/issues/116

Whole npm ecosystem is so fragile.

Remember event-stream[1]? Did we learned something from that? Yes, we might. So was it improved? Never. People are still installing 'new' colors package and wondering why its texts are broken.

What if he uploaded malicious code rather than just just gibberish?

[1]: https://github.com/dominictarr/event-stream/issues/116

foo-bar version 1.0 depends on bada-boom 1.0 which depends on bada-bing 1.0. Now you update to foo-bar 1.1 because of some critical update, which in itself now depends on bada-boom 2.0 and bada-bing 2.0. But unbeknownst to you and the author of foo-bar, the bada-boom and bada-bing project was taken over by another maintainer who made an update, but also added some trojan horse code to specifically attack certain users, which was obfuscated and remained undetected. Which has happened before - not just browser extensions are affected by malicious attackers taking over useful projects.