[kazlock]

> two modules will tend to grow ever more dependent on each other unless separated by hard ('physical') boundaries

This is especially true in monorepos. Code resuse has it's benefits, but left unchecked the dependency graph can turn into a huge highly-connected glob. Modules end up accidentally importing code they have no business importing because of sneaky transitive dependencies. The blast radius of even small simple changes becomes enormous, and testing/debugging becomes more and more complex.

A great way to keep this in check is to have apply code isolation in the test environment. When you checkout the entire repo for a build or test, its easy for these kinds of dependencies to grow unnoticed. But if you require build/test targets to explicitly declare what code they depend on (and only make that code present when running them), changes to the dependency structure must be explicitly acknowledged in code review. This is one of the core principles behind build tools like Bazel.

[KajMagnus]

> This is especially true in monorepos

Not in my monorepo.

I have compile time boundaries between modules and I cannot make them particularly entangled with each other.

Maybe the problem you have in mind, is more likely to happen in dynamically typed languages? Where there's no compiler who can say "No."

[sitkack]

Even in monorepos, calls into a module should go through a versioned interface.

[Groxx]

In general I agree, because it allows gradual migration of users... but in essentially every case I've seen, removing versioned interfaces is billed as the primary feature of monorepos.

[sitkack]

I just realized monorepos are analogous to a flat network, everything can reach everything else, or that main memory is flat/linear/same cost for each read/write (not true, but it is the abstraction we believe).

I now believe that monorepos can only work well when there is a mechanical tool for ensuring correctness and that refactorings can be done atomically across the whole tree. Infact, it might be necessary to _only_ commit the refactoring operation to the tree and the source itself. That the whole tree is a blockchain of tree edit operations.

[KajMagnus]

> monorepos can only work well when there is a mechanical tool for ensuring correctness and that refactorings can be done atomically across the whole tree

Isn't a compiler such a tool? I use a statically typed language, and if I would try to do this:

> everything can reach everything else

then there'll be compilation errors.

[Groxx]

which is one of the reasons I like microrepos and versioning: you can do refactorings across subtrees. if there's an edge case you want to address later, you can address it later. if you eschew versioning entirely, you effectively have no choice but to do everything all-or-nothing.

[j88439h84]

I'm not familiar with that, how does it look? Docs maybe