3 ms·

Having seen a large org attempt a poly -> mono repo conversion project (which took almost 2 years and failed and was in the process of being rolled back when I

Having seen a large org attempt a poly -> mono repo conversion project (which took almost 2 years and failed and was in the process of being rolled back when I left) I agree with everything in this article Once an org becomes large enough you need lots of custom tooling to make working across a huge codebase smoother, and that tooling is similar for mono and poly repos, but you need an additional metric ton of tooling to make monorepos work And please pray you didn't decide to go with bazel for builds My least favourite monorepo experience: I want to update my dependency for my tiny service for a security patch -> Oh, 400 other services depend on it and dozens of tests break when I try to update it -> this isn't worth my time I'll do something else instead We were promised a world where every dependency was kept up to date by necessity but ended up in a world where all dependencies atrophied due to the increased difficulty to update them

jpc0 2y ago
> I want to update my dependency for my tiny service for a security patch If the API changed it's not a security patch... Why would a change that only fixes a security bug cause tests to fail? Sounds like this is more a matter of needing to cherry-pick temporarily and then actually pushing for the codebase to update, probably by the security team. Sometimes you need to work with other people, that might necessitate doing "ugly" things to get the job done.
- thornygreb 2y ago
  Yes, but very often you are trucking along just fine with some version of a dependency and then all of a sudden it gets a CVE and the fix has only been applied to the next major version and not backported because the version you are on is no longer supported. And now you are in dependency update cascading hell.
tdb7893 2y ago
Having worked at a place with a monorepo it was one of the things I actually really liked about working there. It took a lot more tooling but I found it to be much better than a multi-repo would have been, even with a similar amount of tooling. I didn't have to be checking different projects out all the time and changes across projects weren't too bad (large scales ones still took a lot of managing but not as much as changes across a multi-repo). I was always hoping that one of the big cloud providers would offer a monorepo and invest a lot in making tooling for it to actually be usable.
karmakaze 2y ago
This actually explains why Google is so keen to retire products that don't necessarily cost much to run, but don't turn a profit yet.
patrick451 2y ago
> And please pray you didn't decide to go with bazel for builds Why not? And what should one use instead?

jpc0 2y ago

> I want to update my dependency for my tiny service for a security patch If the API changed it's not a security patch... Why would a change that only fixes a security bug cause tests to fail? Sounds like this is more a matter of needing to cherry-pick temporarily and then actually pushing for the codebase to update, probably by the security team. Sometimes you need to work with other people, that might necessitate doing "ugly" things to get the job done.

thornygreb 2y ago
Yes, but very often you are trucking along just fine with some version of a dependency and then all of a sudden it gets a CVE and the fix has only been applied to the next major version and not backported because the version you are on is no longer supported. And now you are in dependency update cascading hell.

tdb7893 2y ago

Having worked at a place with a monorepo it was one of the things I actually really liked about working there. It took a lot more tooling but I found it to be much better than a multi-repo would have been, even with a similar amount of tooling. I didn't have to be checking different projects out all the time and changes across projects weren't too bad (large scales ones still took a lot of managing but not as much as changes across a multi-repo). I was always hoping that one of the big cloud providers would offer a monorepo and invest a lot in making tooling for it to actually be usable.

karmakaze 2y ago

This actually explains why Google is so keen to retire products that don't necessarily cost much to run, but don't turn a profit yet.

patrick451 2y ago

> And please pray you didn't decide to go with bazel for builds Why not? And what should one use instead?