This makes no sense, because the only reason React would suddenly fail on you is if your project is so very badly engineered that you don't pin dependencies and cache them locally. And even then, your deployed instances would remain unaffected.
A dependency is something you own (a checked-out copy of). A better comparison is with services. So you may be using a payment gateway in your product, and maybe you need just a single one - but at the very minimum, you should have a plan in place to switch to a different one at a moment's notice. That's reasonable redundancy.
I think I've come up with an analogy for demand-side supply chain issues though. Imagine you have a web service that's constantly under 90% load during normal operations, and that eats almost exactly as much money in the infrastructure costs as it earns. Imagine that service gets mentioned on Hacker News. It almost immediately fails due to increased demand, you can't provision new instances because you don't have enough money in the bank, and then when suddenly the demand drops, you can't afford to keep it on at all.
Only a series of very bad decision would cause the above scenario to happen, and yet it's almost exactly like how supply chains operate in physical space.
We could easily imagine that suddenly it is revealed that React contains some super-well-hidden malware that phones home to Facebook, and that's been built into React since early versions. As doubtful as that sounds, it's actually not unlike recent scares about China embedding secret transmitters deep inside of circuitboards, etc.
Again, you own your code dependencies[0]. A patch would be quickly released by software security experts, which every half-competent developer could apply to their product on their own. That's the benefit of ownership - you get to fix things. With software, you don't even need spare parts.
Depending on services is where the fragility starts. They're single points of failure, unless you have a plan to quickly switch to an equivalent competitor.
--
[0] - Unless they have a time-limited commercial license. Then they're essentially a service.
A dependency is something you own (a checked-out copy of). A better comparison is with services. So you may be using a payment gateway in your product, and maybe you need just a single one - but at the very minimum, you should have a plan in place to switch to a different one at a moment's notice. That's reasonable redundancy.
I think I've come up with an analogy for demand-side supply chain issues though. Imagine you have a web service that's constantly under 90% load during normal operations, and that eats almost exactly as much money in the infrastructure costs as it earns. Imagine that service gets mentioned on Hacker News. It almost immediately fails due to increased demand, you can't provision new instances because you don't have enough money in the bank, and then when suddenly the demand drops, you can't afford to keep it on at all.
Only a series of very bad decision would cause the above scenario to happen, and yet it's almost exactly like how supply chains operate in physical space.