3 ms·
In my experience, outside Google monorepo (and maybe Meta, don't know, didn't work there) every monorepo just sucks because it's cargo culting. It's never mono
by progbits 2y ago
In my experience, outside Google monorepo (and maybe Meta, don't know, didn't work there) every monorepo just sucks because it's cargo culting.
It's never monorepo. It's one big repo and one or two other small repos (because of permissions, secret code, whatever), copypasted code between repos because people don't set up proper packaging, semi broken builds everywhere because of poor static analysis, and so on.
Unless you are willing to really commit (ha!) to monorepo and all the tooling and devex support that requires, just stick to multiple small repos.
- osigurdson 2y agoDo you share code at all between the repos via package managers or just accept some duplication? Using packages requires quite a bit more discipline as maintainers need to ensure they don't break consumers. If the code is just in one big repo (maybe horrible for other reasons), all consumers have to be updated or it won't compile. It seems that using binary distribution (vs source) creates a fairly hard problem that doesn't really need to be solved.
- progbits 2y agoYeah if you actually have it all in one repo and have a good build system / tests so CI can make sure you are not breaking anything that is awesome. That is the google/bazel experience. But I've seen "monorepos" where changes to one subfolder break the rest without developers noticing, or cases where a library / API definitions were manually copied from one repo to another instead of being properly packaged.
- playingalong 2y agoWell, multiple small repos is even more copy&paste then.