Scolding and mocking is all we're left with, since two decades worth of rational arguments against these types of hazards have been dismissed as fear-mongering.

I don't think we're going to reach a point where "don't use dependencies at all" is a rational argument for most projects.

It's a good thing then that was not among the rational arguments I was referring to. Do you have other straw men on offer?

Time for everybody's favorite engineering answer: it depends! You have to weigh the cost/benefit tradeoff. But you have to do it in full awareness of the costs, including potential costs from packages being taken down, broken, or subverted. In any case, for an external dependency, 100 lines is way too low of a benefit.

I'm not trying to be effective, I'm just lamenting. Maybe being sarcastic isn't a very effective way to get people to be effective?

Naw, sarcasm totally works... ;)

I'd say it all depends -- there's that word again -- on what those 100 LOC are expressing. I suppose one could still copy/paste such a small amount of code, but I'd rather just check in some subset of vendored dependencies. Or maybe just pin the dependency to a commit hash (since we can't depend on version tags being immutable). Something actionable beyond peer pressure at any rate.

There are definitely 100-line chunks of code I wouldn't want to rewrite from scratch. They also tend not to be the sort of thing that needs a lot of updates, so a copy/paste job ought to do the job.

The big advantage with a dependency manager is that you don't have to find all of the dependency's dependencies, figure out the right build settings, etc. That's super helpful when it's huge, but it's not really doing anything for you when it's small.