4 ms·

Monorepo lets me have a _single_ Github PR with the changes across 4 projects in front of me. To replicate what you're talking about in a multirepo setup, you h

by rtpg 4y ago

Monorepo lets me have a _single_ Github PR with the changes across 4 projects in front of me. To replicate what you're talking about in a multirepo setup, you have to introduce changesets in 4 different places, then merge them in the right order, make a bunch of tiny releases, update commit hashes to point to the right one, and do a lot of other bookkeeping because in this house we keep our projects separated.

Galanwe 4y ago
Indeed, the small additional bookkeeping is the price to pay. I'm quite used to it, so I don't even see it anymore. Is that all? These 5 less minutes of bookkeeping are the killer feature of monorepos? Because, as far as I see it, there's an insane amount of engineering to make a monorepo work even at small scale. Are these 5 minutes per multi-project PR worth it? I wouldn't be surprised these 5 minutes are largely offsets solely by the additional hours of CI testing time introduced by having to run tests on the whole monorepo at each commit instead of just the project that changed.
- alecthomas 4y ago
  > hours of CI testing time introduced by having to run tests on the whole monorepo at each commit instead of just the project that changed. This is rarely the case. Most monorepos shard tests such that wall time is minimised and have dependency analysis that only runs tests affected by the changed code. More of a problem is that IDEs and LSPs often don't deal well with having to index and navigate very large codebases. I've maintained both monorepo and polyrepo environments and there are pros and cons to both, and they vary _wildly_ based on the language being used.
- rtpg 4y ago
  5 minutes? Bit of an underestimation. Also I used bazel in my previous monorepo setup… so not really paying a huge CI cost.
- Groxx 4y ago
  Yeah. They reduce the time spent on rare (but relatively valuable!) events, and massively increase time spent on all the little things you do dozens or hundreds of times per day. It adds up quite badly for everyone except the monorepo managing teams.

by rtpg 4y ago

Galanwe 4y ago

Indeed, the small additional bookkeeping is the price to pay. I'm quite used to it, so I don't even see it anymore. Is that all? These 5 less minutes of bookkeeping are the killer feature of monorepos? Because, as far as I see it, there's an insane amount of engineering to make a monorepo work even at small scale. Are these 5 minutes per multi-project PR worth it? I wouldn't be surprised these 5 minutes are largely offsets solely by the additional hours of CI testing time introduced by having to run tests on the whole monorepo at each commit instead of just the project that changed.

alecthomas 4y ago
> hours of CI testing time introduced by having to run tests on the whole monorepo at each commit instead of just the project that changed. This is rarely the case. Most monorepos shard tests such that wall time is minimised and have dependency analysis that only runs tests affected by the changed code. More of a problem is that IDEs and LSPs often don't deal well with having to index and navigate very large codebases. I've maintained both monorepo and polyrepo environments and there are pros and cons to both, and they vary _wildly_ based on the language being used.
rtpg 4y ago
5 minutes? Bit of an underestimation. Also I used bazel in my previous monorepo setup… so not really paying a huge CI cost.
Groxx 4y ago
Yeah. They reduce the time spent on rare (but relatively valuable!) events, and massively increase time spent on all the little things you do dozens or hundreds of times per day. It adds up quite badly for everyone except the monorepo managing teams.