I would like to draw to your attention the magnitude of that task, with a recent link from another HN comment discussion:

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...)

In react's case you put your trust in facebook and because of the size most issues get discovered and someone has an article on how to fix before breakfast.

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 think that's exactly the problem because of things like this: https://twitter.com/ZacSweers/status/1259176799235387393?s=1...

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.

Let's say this doesn't get updated I don't see a problem. It will continue to function as it is until it gets outdated and replaceed. Let's say it changes and does something evil, hopefully Google, Microsoft will catch the issue. If they don't someone will and people will stop trusting react or whatever product pulls these changes in.

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.

Lets just say someone at booking.com or tripping.com or some other hungry and less-that-totally-ethical AirBNB competitor works this out, and offers to buy the library or pay Zac $bignum in return for adding in some "additional analytics" aka industrial espionage allowing them to see searches/bookings made by users of apps with the library embedded.

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...

What if I have no reasonable way of fully understanding the code nor being able to judge the author on their trustworthiness (even disregarding that this isn't constant).

As a community we need to accept that the above mentioned DOES happen. Pretending otherwise only hurts us all.

> 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.

Hands up everybody who remembers "Matt's Script Archive"?

(Hmmm, just the greybeards. I could have guessed that I suppose...)

One way to judge that is by whether the project was consistently maintained, what kind of issues are reported and if the important ones are fixed.

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.

There are many things short of reading the code in full you can do to lower the chances of this happening. A lot of half-assed libraries have obviously incomplete APIs that you can notice if you think about the interface provided and the nature of what the library claims to be doing. You can also look at repo activity; was it all coded in one week 8 years ago and never touched again? Does it have lots of outstanding issues?

Some things may slip through the cracks, but filtering out most of the chaff can be done without reading every line of source.

This. In my experience, GitHub issues and PRs tell you most everything you need to know about an open source library: if issues are responded to (and how quickly), the attitude of the maintainer with regards to new features, etc. Most of this can be gleamed within 20 minutes of browsing, and when you combine that with a quick 5-minute look at dependencies and tests, you can make a pretty good, educated decision about whether to use the library, and those 25-30 minutes save you hours or days of potential headaches down the road.

Most of time it's just trust. It's not possible to read through node modules, or reason about C compilers, or even inspect the source code of the operating systems.

Who has read through all the code of their direct dependencies, let alone transitive ones?