5 ms·
> 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 r
by kazlock 7y ago
> 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.
- sitkack 7y agoEven in monorepos, calls into a module should go through a versioned interface.
- j88439h84 7y agoI'm not familiar with that, how does it look? Docs maybe
- Groxx 7y agoIn 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 7y agoI 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 7y ago> 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 7y agowhich 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.
- KajMagnus 7y ago> 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."