You have found a local optimum that involves multiple repos. Others have found a local optimum that involves a single repo. Arguments for mono-repos are not arguments against multi-repos.
For some background: we migrated from multi-repo to mono-repo to solve several pain points, which are touched on in TFA. It's fair for you to state that you have never had a problem, or that you don't see it, but don't conclude that no one else has ever had that problem, or that they, unlike you, consider that problem to be important enough to need a solution.
> [Single source of truth] has never been a problem for me. You have an app in one repo depending on a version of a package built from another.
But I don't have a package built from another. To support multiple repos, do I need to configure package creation, set up an artifact server, and teach the team how to use a locally-built package for debugging/prototypes ?
> There are lots of changes you can make that the monorepo doesn't detect any more than a multi-repo
There are several techniques for working on a large codebase that involve making easy-to-detect changes, that can then followed to both explore the extent of what the work should cover, and ensure that no piece is forgotten. Having a monorepo makes it easier to put all the code in one place for the static analysis tools to crunch through.
> I don't agree that finding existing functionality to reuse is easier. How so? You search for "Tokenize" and hope to find something relevant?
You can "Find all references" of a specific type to identify functions that can operate on it. The list will usually be short enough to scan in a minute or two. If you're looking for a function to frobnicate that type, it will almost certainly be in the list. I'm not sure how you would this on packages from several repos (especially if that function is non-public).
> "Change the code and get proper reviews", this is nothing to do with monorepos.
My current tooling does not allow me to submit a PR that pushes two different commits to two different repos. If using packages to share code between repos, it also means that the change must deal with package versioning.
There exists a set of tools, techniques and never-been-a-problems that can make mono-repo work and be productive, just like there exists a set of tools, techniques and never-been-a-problems that can do the same for multi-repos.
For some background: we migrated from multi-repo to mono-repo to solve several pain points, which are touched on in TFA. It's fair for you to state that you have never had a problem, or that you don't see it, but don't conclude that no one else has ever had that problem, or that they, unlike you, consider that problem to be important enough to need a solution.
> [Single source of truth] has never been a problem for me. You have an app in one repo depending on a version of a package built from another.
But I don't have a package built from another. To support multiple repos, do I need to configure package creation, set up an artifact server, and teach the team how to use a locally-built package for debugging/prototypes ?
> There are lots of changes you can make that the monorepo doesn't detect any more than a multi-repo
There are several techniques for working on a large codebase that involve making easy-to-detect changes, that can then followed to both explore the extent of what the work should cover, and ensure that no piece is forgotten. Having a monorepo makes it easier to put all the code in one place for the static analysis tools to crunch through.
> I don't agree that finding existing functionality to reuse is easier. How so? You search for "Tokenize" and hope to find something relevant?
You can "Find all references" of a specific type to identify functions that can operate on it. The list will usually be short enough to scan in a minute or two. If you're looking for a function to frobnicate that type, it will almost certainly be in the list. I'm not sure how you would this on packages from several repos (especially if that function is non-public).
> "Change the code and get proper reviews", this is nothing to do with monorepos.
My current tooling does not allow me to submit a PR that pushes two different commits to two different repos. If using packages to share code between repos, it also means that the change must deal with package versioning.
There exists a set of tools, techniques and never-been-a-problems that can make mono-repo work and be productive, just like there exists a set of tools, techniques and never-been-a-problems that can do the same for multi-repos.