> Sure it's simple but it makes it hard to find anything if you have a lot of stuff/people.
I think this is a bad analogy. Looking up a file or directory in a monorepo isn't harder than looking up a repository. In fact, I'd argue it's easier, as we've developed decades of tooling for searching through filesystems, while for searching through remotely hosted repositories you're dependent on the search function of the repository host, which is often worse.
Note: for the sake of discussion I’m assuming when we say monorepo we mean monorepo and associated tools used to manage them
The trade off is simplified management of dependencies. With a monorepo, I can control every version of a given dependency so they’re uniform across packages. If I update one package it is always going to be linked to the other in its latest version. I can simplify releases and managing my infrastructure in the long term, though there is a trade off in initial complexity for certain things if you want to do something like say, only run tests for packages that have changed in CI (useful in some cases).
It’s all trade offs, but the quality of code has been higher for our org in a monorepo on average
I've found that many developers do not pay attention to dependency management, so this approach of "it's either in the repo or it doesn't exist" is actually a nice guard rail.
I'm reading between the lines here, but, I'm assuming you've setup your tooling to enforce this. As in: the various projects in the repo don't just optionally decide to have external references, i.e., Maven central, npm, etc.
This puts quite a lot of "stuff" in the repo, but with improvements like this article mentioned, makes monorepos in git much easier to use.
I'd have to think, you could generate a lot of automation and reports triggering out of commits pretty easily, too. I'd say that would make the monorepo even easier to observe with a modicum of the tooling required to maintain independent repositories.
That is accurate, I wouldn't use a monorepo without tooling, and in the JavaScript / TypeScript ecosystem, you really can't do much without tooling (though npm supports workspaces now, it doesn't support much else yet, like plugins or hooks etc).
I have tried in the past, trying to achieve the same goals, particularly around the dependency graph and not duplicating functionality found in shared libraries (though this concern goes in hand with solving another concern I have, which is documentation enforcement), were just not really possible in a way that I could automate with a high degree of accuracy and confidence, without even more complexity, like having to use some kind of CI integration to pull dependency files across packages and compare them, in a monorepo I have a single tool that does this for all dependencies whenever any package.json file is updated or the lock file is updated
If you care at all about your dependency graph, and in my not so humble opinion every developer should have some high-level awareness here in their given domain, I haven't found a better solution that is less complex than leveraging a monorepo
Sure it's simple but it makes it hard to find anything if you have a lot of stuff/people. submodules and package managers exist for a reason.