[danpalmer]

Being a monorepo is typically about more than just how code is stored, it leads to very different practices about dependency management, building, etc. On the monorepo I work on, the fact it is a monorepo is intrinsically linked to the build, testing, and deployment processes in many ways.

The ideal is that your build system by-necessity contains the data to be able to selectively test – typically the case if you're linking code in some way. You import a library, now your tests get run if that library changes. As the article suggests, this breaks down over service boundaries, but as you suggest, you still hopefully have modules you can link up.

The problem is when you have hundreds of services, maintaining those dependencies manually could be hard. When you have thousands it may be nearly impossible. When you have hundreds of thousands it may be impossible. I think applying ML to that problem so that you can incrementally understand the ever changing dependencies across services.

I can also assure you that however smart the build system is, there will always be spooky action at a distance between components.

[mhlakhani]

yeah. I am talking about repos with hundreds of thousands (probably millions) of tests. Here's just one example of the scale: https://engineering.fb.com/2018/11/21/developer-tools/predic...

if you change a low level library that's the equivalent of the C++ standard library and you want to test the changes, you effectively have to rebuild the world. And you don't want to.

[danpalmer]

Exactly, or when "one" build rule connecting a service to another is actually a hundred deeply nested build rules doing a lot more work, and every one of those code paths would need to correctly convey whether a dependency is required at the test level or not.