5 ms·
My company has been moving towards having monorepos per language stack. Decent compromise
by DanielHB 1y ago
My company has been moving towards having monorepos per language stack. Decent compromise
- Kinrany 1y agoThat sounds worse than either option. At that point put it all in one repo with a directory for each language.
- amelius 1y agoThis will start to become a problem if the stacks need to communicate with each other using versioned protocols.
- NiloCK 1y agoMaybe I miss the point here, but it seems to me that versioning the protocols is the specific solution to maintaining interop between different implementations.
- lolinder 1y agoWhy can't you just use versioning in your external-to-the-monorepo APIs and use HEAD within the monorepo? Nothing about combining some projects into a monorepo forces you into dropping everything else we know about software release cycles.
- amelius 1y agoThe point is that it is more work.
- lolinder 1y agoMore work than what? More work than sharing HEAD in the monorepo, certainly. But it's definitely not more work than versioning across multiple repos because it's literally the same thing. When you're exporting code from a monorepo you follow all the same patterns you would from a small single library repo.
- jolt42 1y agoCoupling and Cohesion likely has nothing to do with the language.
- aldanor 1y agoAnd then at some point your Rust people write a Python module in Rust via pyo3, and it has to be integrated into Python build system and Python type checkers, but also needs local rust crates as build dependencies and local python packages as runtime dependencies... hm.