2 is simple. Import everything you need to depend on into the repo. Google has 3rdparty directory in its mono repo to put them.

That's an approach. Don't know if I'd call it simple. Your monorepo would start looking like an artifact repository at some point, with multiple versions of products.

And Google's approach, I'm sure, requires a bit of standardization and tooling investment. It's not clear to me that equivalent conformance and investment in monorepos and a package manager wouldn't work just as well.

>Your monorepo would start looking like an artifact repository at some point, with multiple versions of products.

It shouldn't, that's one of the big gains of a monorepo, is that there's only one version of everything. You don't need to version your dependencies within the repo, which means you only need to maintain one version of any external dependency.

I wouldn't call getting every project, internal or external, on the exact same version of every dependency "simple". That's a lot of hand waving around a really hard problem.

Its hard to do if you don't start out that way early on, yes. I don't really think its hard to maintain that state.

With multi-repo environments, btw you still need to do that kind of dependency version management for certain upgrades. Essentially you can desync but you have to occasionally re-sync everything. I na monorepo environment you can just prevent desynchronization.

It's a hard problem, but it's not necessarily harder than other approaches to dependency management. There's pretty much no approach to dependency management that isn't hard in one way or another.

A large chunk of third party usage is open source Google libraries like Guava. Anecdotally, I don't end up using that many libraries from third party.

As for JavaScript, the hassle of importing the entire transitive closure of an NPM library you want into third party means it's much more attractive to go with NIH syndrome. I looked at importing ESLint, but it has something like 110 dependencies.