2 ms·

The #1 benefit for me regarding the monorepo strategy is that when someone on the team refers to a commit hash, there is exactly one place to go and it provides

The #1 benefit for me regarding the monorepo strategy is that when someone on the team refers to a commit hash, there is exactly one place to go and it provides a consistent point-in-time snapshot of everything. Ideally, all of the commits on master are ~good, so you have approximately a perfect time machine to work with. I have solved more bugs looking at diffs in GitHub than I have in my debugger simply by having everything in one happy scrolly view. Being able to flick my mouse wheel a few clicks and confirm that the schema does indeed align with the new DTO model props has saved me countless hours. Confirming stuff like this across multiple repos & commits can encourage a more lackadaisical approach. This also dramatically simplifies things like ORM migrations, especially if you require that all branches rebase & pass tests before merging. I agree with most of the hypothetical caveats, but if you can overcome them even with some mild degree of suffering, I don't see why you wouldn't fight for it.

hu3 2y ago
I've seen teams take this even further and vendor all dependencies. This way a commit hash contains even the exact third party code involved.
- yurishimo 2y ago
  This is perfectly fine if your language of choice doesn’t have a robust package manager that supports version pinning. But then you need to enforce pinning across your org which could prove its own challenge.
  - hu3 2y ago
    Why only restrict to these cases? One of the teams vendored npm and go packages which are robust. Code always ran inside Docker. Being able to just clone and run simplified their flow.
IshKebab 2y ago
I don't see how that relates to monorepos. Even using submodules a single commit hash will specify the commit hashes of every submodule (usually; you can actually set up submodules to point to a branch instead of a commit but I've never seen anyone do this). There are definitely huge benefits to monorepos but I don't see how this is one.
- actinium226 2y ago
  With submodules you end up doing this dance where you have to do the following steps in order to make a change: 1) Create a PR in the submodule with your changes and create a PR in the main repo with the submodule hash replaced with the one in the 1st PR 2) Merge the submodule PR (now the main repo is pointing at an out of date hash in the submodule) 3) Go back to the main repo PR, update the hash, rerun tests, merge it (assuming tests pass) It often feels burdensome, particularly when you need to change a single line of code in the submodule. It invites race conditions when multiple people work on the submodule simultaneously (so in step 3 above your tests might not pass because somebody else merged something into the submodule repo in between 1 and 2). It also creates weirdly ambiguous situations like what if someone updates the documentation in the submodule - do you update the main repo, or do you simply allow the main repo to lag behind the submodule's master branch?
  - fwip 2y ago
    I haven't used submodules much (just one project for a few years), but the only flow that seemed to work is "never commit changes in the submodule." You can change the code locally on-disk for testing, then submit your changes to upstream. Once you've got an upstream ref (preferably after merge), then you can update the submodule to match. This does slow everything down though, unless you're cleverer about CI and deployment than we were (very possible).
    - IshKebab 2y ago
      I think you're conflating submodules with vendoring.
      - fwip 2y ago
        That's one way to describe our strategy, yeah. We used submodules technically to basically vendor our dependencies. Our "upstream" was other people in the same org with whom we had a good working relationship, so our patches generally got merged within a day or two.
  - 2y ago

hu3 2y ago

I've seen teams take this even further and vendor all dependencies. This way a commit hash contains even the exact third party code involved.

yurishimo 2y ago
This is perfectly fine if your language of choice doesn’t have a robust package manager that supports version pinning. But then you need to enforce pinning across your org which could prove its own challenge.
- hu3 2y ago
  Why only restrict to these cases? One of the teams vendored npm and go packages which are robust. Code always ran inside Docker. Being able to just clone and run simplified their flow.

IshKebab 2y ago

I don't see how that relates to monorepos. Even using submodules a single commit hash will specify the commit hashes of every submodule (usually; you can actually set up submodules to point to a branch instead of a commit but I've never seen anyone do this). There are definitely huge benefits to monorepos but I don't see how this is one.

actinium226 2y ago
With submodules you end up doing this dance where you have to do the following steps in order to make a change: 1) Create a PR in the submodule with your changes and create a PR in the main repo with the submodule hash replaced with the one in the 1st PR 2) Merge the submodule PR (now the main repo is pointing at an out of date hash in the submodule) 3) Go back to the main repo PR, update the hash, rerun tests, merge it (assuming tests pass) It often feels burdensome, particularly when you need to change a single line of code in the submodule. It invites race conditions when multiple people work on the submodule simultaneously (so in step 3 above your tests might not pass because somebody else merged something into the submodule repo in between 1 and 2). It also creates weirdly ambiguous situations like what if someone updates the documentation in the submodule - do you update the main repo, or do you simply allow the main repo to lag behind the submodule's master branch?
- fwip 2y ago
  I haven't used submodules much (just one project for a few years), but the only flow that seemed to work is "never commit changes in the submodule." You can change the code locally on-disk for testing, then submit your changes to upstream. Once you've got an upstream ref (preferably after merge), then you can update the submodule to match. This does slow everything down though, unless you're cleverer about CI and deployment than we were (very possible).
  - IshKebab 2y ago
    I think you're conflating submodules with vendoring.
    - fwip 2y ago
      That's one way to describe our strategy, yeah. We used submodules technically to basically vendor our dependencies. Our "upstream" was other people in the same org with whom we had a good working relationship, so our patches generally got merged within a day or two.
- 2y ago