> Splitting your code over many repositories massively increases the cost of refactoring, making it that less likely that your system will be "well factored" T

> Splitting your code over many repositories massively increases the cost of refactoring, making it that less likely that your system will be "well factored" The project should stay a full monolith until the factoring is more clear. > I find this to be this a level headed explanation of the advantages of monorepos: https://danluu.com/monorepo/ https://danluu.com/monorepo/. There are two issues I have with this article. One of them is when it describes drawbacks of multiple repositories, its not specific enough e.g. > That sounds like it ought to be straightforward, but in practice, most solutions are cumbersome and involve a lot of overhead. The other is that it assumes you have Google scale of resources to throw at the problem. If thats the case you can make anything work / monorepos or polyrepos. The issue is that small-to-medium sized organizations will not be prepared to invest the amount of resources needed to keep a monorepo working well, as the org will largly need to rely on existing available (OSS) tools which often have poor monorepo support. (Bazelifying everything has a significant cost, bazel rules are often not generic enough to work with e.g. the variety of JS ecosystem tools)