Yes you must read and understand everything or have trust in the publisher. Relying on the package name is going to get you in trouble. Sounds like a great exploit opportunity.
http://npm.anvaka.com/#/view/2d/react-native
and
https://github.com/microsoft/react-native-windows/blob/maste...
Turns out left-pad.js is on line 8571 of that 14+k line yarn.lock file.
How many React Native developers do you suppose have reviewed every line of code in every library referenced in that file? (Or even how many engineering teams at any React-using Unicorn size startups or FAANG have exhaustively reviewed all those lines of code?)
Is FaceBook a "trusted publisher" of React? Is npm a "trusted publisher" of Node libraries? Was Azer Koçulu a "trusted publisher" of left-pad.js?
(And it's turtles all the way down. Is Microsoft a "trusted publisher" of Windows? Is Dell a "trusted publisher" of bios? Is Intel a "trusted publisher" of cpu micro-code? Is Western Digital a "trusted publisher" of hard drive firmware? Is every unnamed silicon manufacturer and pcb and subcomponent assembly house a "trusted publisher" of the embedded code in their network card/usb hub/battery management chip/whatever?)
I _do_ agree with you, but these days it's very difficult, at least in much/most of the software world, to determine the height of the people/libraries claiming to be "giants" offering their shoulders to stand on. (And like with React, it's more and more difficult to determine which actual giants are standing on bedrock, and which have a foothold with quicksand uderneath it...)
When you include left-pad in your own project you should audit it. In the end you are the only line of defense. With react it's larger so you can trust others.
I am the sole maintainer of airbnb/lottie-android despite the fact that I left the company almost 2 years ago and it is used by tens of thousands of companies including Google, Samsung, Microsoft, Uber, Netflix, and countless others.
Doing it yourself I would just freeze versions.
---------
In this case I find it odd for someone to keep maintanier status for a company repo they no longer work for 2 years after leaving.
I would have forked and introduced new changes in my own repo if I cared about the project. Let others follow if they desire new updates or force airbrb to assign someone to update. or better get airbrb to pay you to keep updating.
Now Zac probably isn't the sort of person who'd do that, but once you get to a project like React which has 10,000 or so dependancies - surely _some_ of those dependancy authors would do that, for enough pieces of silver...
As a community we need to accept that the above mentioned DOES happen. Pretending otherwise only hurts us all.
In fact, it happens very often when people are learning and exploring. So imagine I publish my shitty library "with a generic name and a description talking about how awesome it is". Imagine you're trying to learn $language. You buy into my deception and try to use my library. You get burned, and might be left with an impression that $language or its ecosystem is shitty, and never return, despite the fact that $language would suit the kinds of problems you're solving really well. If it happens enough times with enough libraries, $language may get a bad reputation. Preventing this becomes a matter of protecting the common good.
(Hmmm, just the greybeards. I could have guessed that I suppose...)
So if the project seems to be ignored (no issues), if it has tons of them and no response, you won't use it or use it only with caution.
Newcomer to langue or ecosystem should use popular frameworks and libraries, so that there is help available.
Some things may slip through the cracks, but filtering out most of the chaff can be done without reading every line of source.