> It really only works if you primarily work in a single monorepo.

That's simply not true; it doesn't come down to "monorepo-or-not?"

It comes down to whether or not the code size of an app's dependencies and transitive dependencies is still reasonable or has gotten out of control.

The trend of language package managers to store stuff out of repo (and their recent, reluctant adoption of lockfiles to mitigate the obvious problems this causes*) is and always has been designed to paper over the dependency-size-is-out-of-control problem—that's the reason that this package management strategy exists.

You can work on dozens of projects (unrelated; from disjoint domains) that you maintain or contribute to while having all the source for every library/subroutine that's needed to be able to build the app all right there, checked into source control—but it does mean actually having a handle on things instead of just throwing caution to the wind and sucking down a hundred megabytes or more of simultaneously over- and under-engineered third-party dependencies right before build time.

It's no different from, "Our app consumes way too much RAM", or, "We don't have a way to build the app aside from installing a monstrously large IDE" (both belonging to the category of, "We could do something about it if we cared to, but we don't.")

> There is actually a huge difference between checking in all of your dependencies and checking in a lock-file.

Yes, huge difference indeed: the hugeness of YOLO maintainers' dependency trees.

* what could possibly go wrong if we devise a scheme to subvert the operations of a tool where the entire purpose of it was to be able to unambiguously keep track of the revisions/content of the source tree at a given point in time?