12 ms·

I know it‘s an April‘s fool. But I don’t get this recent trend of people arguing in favor of a monorepo (at my work place, too). It’s a nightmare to handle and

I know it‘s an April‘s fool. But I don’t get this recent trend of people arguing in favor of a monorepo (at my work place, too). It’s a nightmare to handle and use. What gives?

frizlab 3y ago
Glad to see I’m not the only one thinking that.
paulgdp 3y ago
NixOS uses a monorepo and I think everyone loves it. I love being able to easily grep through all the packages source code, and there's regularly PRs that harmonizes conventions across many packages. Nixpkgs doesn't include the packaged software source code, so it's a lot more practical than what Debian is doing. Creating a whole distribution often requires changes synchronized across many packages, so it really makes things simpler. https://github.com/NixOS/nixpkgs https://github.com/NixOS/nixpkgs I think it's important to add that they both have the biggest number of packaged software and the most up-to-date software of all distributions even though they have far fewer maintainers than Debian. https://repology.org/repositories/graphs https://repology.org/repositories/graphs
- bjornsing 3y ago
  > Nixpkgs doesn't include the packaged software source code, so it's a lot more practical than what Debian is doing. This is the key difference. OpenWRT is a “monorepo” too, but it downloads tar balls etc of the upstream software. Makes sense. Putting the source code of the upstream software in a monorepo sounds like a nightmare…
- thegeekpirate 3y ago
  > I think it's important to add that they both have the biggest number of packaged software and the most up-to-date software of all distributions even though they have far fewer maintainers than Debian. Only because of https://www.reddit.com/r/NixOS/comments/zp95a2/comment/j5ko9kp/ https://www.reddit.com/r/NixOS/comments/zp95a2/comment/j5ko9... I also had plenty of issues with either packages not being available or not building, last I tried. At least with the AUR, it's generally only the latter you have to worry about ;)
  - paulgdp 3y ago
    Yeah, automation in Nixpkgs is crazy and goes far beyond any other distros (that I know of). Why spend manual time when it can be automated?
- viraptor 3y ago
  Is nixpkgs really a monorepo as usually discussed? It's got packages, os modules, and some supporting scripts. Nix itself lives in a different place, so does the RFC planning, system artwork and a few other things. I would expect it all together to become a monorepo. > even though they have far fewer maintainers than Debian. Debian has ~1.5k contributors, nixpkgs lists >3.5k maintainers. (Although that list is not pruned over time)
  - paulgdp 3y ago
    > Is nixpkgs really a monorepo as usually discussed? It's got packages, os modules, and some supporting scripts. Nix itself lives in a different place, so does the RFC planning, system artwork and a few other things. I would expect it all together to become a monorepo. I think we can say it's a monorepo of packages in this context. Not everything from the Nix ecosystem is there. It could also bundle the website, wiki, doc etc but I don't think it matter too much. > Debian has ~1.5k contributors, nixpkgs lists >3.5k maintainers. (Although that list is not pruned over time) Thanks for the info, I heard that a long time ago and never checked myself! It's probably less as you say but still probably bigger than Debian. I guess it makes sense because it's so much easier to contribute there than to Debian.
andyferris 3y ago
It probably depends on your project size, but I am one of those that find them easier to handle. What do you find nightmarish?
baq 3y ago
a hundred small repos are a different kind of nightmare. the truth is, having a large code base is just hard no matter which way you handle it. you'll end up with custom repo tooling for the monorepo or blown up CI/CD infrastructure for many small repos either way. complexity will be conserved; it can be transferred, but can't be removed.
- fragmede 3y ago
  baq's law of code thermo dynamics: complexity cannot be removed. it can be transferred but can not be removed. your CI/CD system will be as complicated as your repo structure isn't.
  - actionfromafar 3y ago
    Saving
Muromec 3y ago
Linux kernel is a monorepo and somehow works. On the other side of the spectrum we have leftpad nonsense and latest xz thing.
dijit 3y ago
it requires a lot of discipline for sure. "It depends" is thrown around a lot; what I've seen working for large companies and on large projects (mostly AAA games, which do use a monorepo typically) is that having a single repo means your dependencies are more likely to be vendored, and updating the vendoring re-runs all tests across all services because dependencies are mapped across the whole project. Incremental build is also something that becomes more possible, rather than constantly building all source from scratch as we tend to do for smaller projects. There's a lot to be said for atomic commits, no "merge trains"[0] and things like a "common library" (that everyone ends up building in a large enough team) are just includes and not entire dependencies with all that entails (versioning, updating dependencies etc;). Having everything in one place also tends to force people to put documentation near their code instead of something else like confluence. It's pros and cons, and the pro's are kind of meek-sounding until you've experienced it. [0]: https://docs.gitlab.com/ee/ci/pipelines/merge_trains.html https://docs.gitlab.com/ee/ci/pipelines/merge_trains.html
Cu3PO42 3y ago
There are real, tangible benefits to monorepos. And real, tangible downsides, too. Like everything else, it's a tradeoff. I'm sure people advocating for them have brought up some benefits. But in case they haven't, here's an example I recently encountered at work: for an application we are developing, we needed functionality X. We knew that we'd need X in other projects, too, so we made it a library. I published it to our internal package registry and referenced it in the project. So far, so good. Turns out, feature X wasn't as well understood as we thought it was and we are still changing things around all the time. That meant: * changing the library * cutting a new release and publishing it * updating dependencies in the project and using the new feature Since this was happening much too often for what was often a one or two line change, I moved the library into the project repo and build it as part of the project pipeline. This removes so much friction around these changes, I find it makes a significant difference. Eventually, I'll move the library back into its own repository, but for now the monorepo is the right choice in my eyes.
- Archelaos 3y ago
  > Turns out, feature X wasn't as well understood as we thought it was and we are still changing things around all the time. If you publish something as a library for someone else, you should generally commit to supporting the public interface of that library as if it were a long-term support release. Exactly how long that should be depends on many factors, of course. But as a rule of thumb, I would recommend supporting this library version for at least two years. If that doesn't make sense, don't release it or look for a subset, where it makes sense.
  - The_Colonel 3y ago
    This is exactly the friction/overhead the other person means and what monorepo works around. (but also keep in mind this is an internal library for likely a couple of internal apps, supporting BC for 2 years is in most cases unwarranted)
    - Repulsion9513 3y ago
      Monorepo doesn't "work around" it, it means you have to support everything (including migrating/BC) on the current version, instead of having to support old stuff on the old version.
frankjr 3y ago
Having to switch branches in different repos to feature-xyz, remember to build it, and then finally work/test is more of a nightmare to me. In a monorepo, you just switch to the branch once, the build system builds everything that needs building, and you are ready to go.
pheatherlite 3y ago
Most developers jump on the hype train and don't stop to think about ramifications or requirements or purpose. Having said that, monorepos have their use cases, and they help eliminate the need to have convoluted tool chains whose entire purpose is to ensure version compatibility between various components of the system... before you can even start making a line of change on the dev machine.. or some asinine docker abstraction that you must spin up... essentially, if everything is in one place (and not conceived by antisocial pranksters), you bet it's meant to be together. This makes it easier for any number of different life cycle teams to pick up a project and not waste time chasing down silly time wasting issues.
ithkuil 3y ago
The opensource tooling to handle large monorepos is just not there. The monorepo at Google with the massively distributed build system and all other tooling make it very effective to work with. You cannot just take one part of that system and expect to magically reap the benefits. The main benefit I see in practice is that you can immediately see which parts of the system are broken by your change immediately as you test your change (as opposed to waiting when integration happen later when dependencies between modules are bumped in a multi-repo)
- IshKebab 3y ago
  I agree it's definitely an underserved tooling area. But so is a maze of submodules which is the realistic alternative. Open source just doesn't care too much about whole-company level projects because those don't really exist in the open source world. That said, you can definitely make it work with Git & Bazel. Beats submodules by a mile.
  - ithkuil 3y ago
    Oh yes. Also another thing: often people end up with the worst of both worlds: one (or two!) big monorepos plus a swarm of many little repos. Now you only pay the price of the monorepo but rarely ever notice the benefits
- necrobrit 3y ago
  >You cannot just take one part of that system and expect to magically reap the benefits. Yeah, specifically people only focus on the "repo" bit. Build system, PRs, history browsing, etc all get handwaved away after you stick all the code in a single repo. These are the extra hard parts though! I think if you were to properly implement "monorepos" in git world it would actually look a lot like a Github _organisation_, rather than a Github repository. Each git "repo" in the "org" would be a workspace with it's own segregated UI so that you can for example check out just that workspace, or see only that workspaces commits or issues -- but some features such as github actions workflow triggers and PRs would be able to span multiple workspaces. Github doesn't really seem to have put much thought into really supporting monorepos though. They have added some support (e.g. codeowners) to support "repo"-as-monorepo, but have also added some features that could go towards supporting "org"-as-monorepo (e.g. dependabot dependency updates and the dependency graph). But it all stops well short of a complete monorepo toolset.
surajrmal 3y ago
I struggle to understand the upside of avoiding monorepos. A lot of people think it means you can't decouple releases, modularize builds and similar with a monorepo, but that's simply not true. The efficiency at which you can refactor and upgrade your codebase cannot be understated.
- IshKebab 3y ago
  The main upsides I see are: * you can pretend you don't need a proper sandboxing build system like Bazel, Buck etc. and stick to Make/CMake etc. * you don't need to learn how to use sparse checkouts It basically lets you avoid learning how to solve the problems you'll inevitably run into for a little while. Not a great reason, but it is a reason.
- sethammons 3y ago
  every monorepo I've seen suffers from a shit CI solution. Other teams break your builds. Builds get longer and more complex. Feedback loops slow down. Engineering velocity slows down. It works at Google because they spent, literally, hundreds of millions of dollars getting it working.
  - knallfrosch 3y ago
    It's not even clear whether a monorepo stretches across teams or not. I think many people are argueing about different things.
Xeamek 3y ago
> It’s a nightmare to handle and use. Why? If all Your work and knowledge is confined in one repo, there still is a way to work only on that part. Or at least there should be. But if You want/need to have access to other parts, it's much easier to use monorepo then to search trough 100 of github repos that are somehow dependent but it's not obvious in what way.
Double_a_92 3y ago
It's much nicer to have everything you could ever need in one place, instead of having to know what is in what repo. Especially when you have versions that need to correspond in the different repos...
gtirloni 3y ago
> It’s a nightmare to handle and use Quite the opposite, IMHO. Juggling dozens of PRs across many repos for a simple change is the definition of a nightmare.
- sethammons 3y ago
  that tells me you prematurely split something. I worked at a high scale, high available system with multiple dozens of teams, each with several repos. If we had to sync changes across repos, we joined the repos because they were, well, joined. In the early days, we had shared libraries and keeping those in sync was a pita. Then we realized we should not be doing what we were doing. The flow should be: (1) update a library and release it, preferring backwards compatible changes or a new major version; (2) code that wants/needs the new functionality updates the usage at its leisure. If you are having to keep multiple repos "in sync" with each other, yes, you picked the wrong abstraction. If the downstream repo(s) need to always be on the latest and greatest version of the library, the library code should be vendored with the calling code.
  - gtirloni 3y ago
    > (2) code that wants/needs the new functionality updates the usage at its leisure. That's how you end up with infinite support costs in a large org. I think the point is that these changes are done atomically.
    - erik_seaberg 3y ago
      You can't deploy a distributed system atomically, and the closer you get the more risk you're taking with prod. The old and new versions need to coexist for at least a couple of weeks in case of rollbacks.
    - sethammons 3y ago
      that is the theory. The reality is that your team can work on fixing an issue now, but the consuming team might be able to get to it next quarter due to competing priorities. Getting multiple teams to agree to work together at the same time is much, much harder than allowing teams to update on their own schedule. You do eventually have to press the organization and deprecate the older thing. The alternative is you do the work for them - which you may or may not have the expertise for, and the other team may not even have time for the needed code review.
jillesvangurp 3y ago
Having lots of small repos also generates overhead they need to be checked out separately, tagged individually, built individually, etc. The reason that this is a bad April first joke is that the idea actually has merit. Google runs their company like this. The unthinkable bit is not doing this technically but Debian rearchitecting the way it works. Doing this with Git is a separate topic. It's probably not great for this. But mono repos at this scale are not impossible.
- SOLAR_FIELDS 3y ago
  There was an article by some well known CTO that hits the nail on the head for me. Essentially they said that monorepo makes sense at small scale and enormous scale (eg Google) but anywhere in between that microservices make more sense. Knowing when you are going to be at those scales is key. In any event, as has been alluded to in this thread already, any complaint about microservices vs monorepo and switching between them is almost always a tooling complaint. Companies will invest in one of these “philosophies” around code organization then won’t take the time to build the appropriate tooling to support them and then three years down the road some enterprising architect will switch from one to the other and the cycle begins anew
Shacklz 3y ago
There have already been a lot of points by other commenters, one point that I'd like to add: It allows to solve "problems of scale" with technical solutions rather than process solutions. For example: Let's say there's application app-A and app-B, and they decide they want a library lib-1 that they can share. If they are in separate repositories, this means multiple pull-requests, it means separate pipelines where the pipeline of lib-1 likely won't include the tests of the applications, it means there will be pull-requests to the library which won't immediately be integrated into the applications so that some poor sod has to take care of breaking changes down the road, etc. If they are in a monorepo, each application can set up tests that need to be fine with the library-code "as is", so any change to the library needs to work against existing application-tests. The price one pays however are pipelines that perform well - nobody wants to wait hours to get pipeline-feedback and such. A monorepo also allows ambitious folks to shine - it's easy to touch many things at once, or to touch things used by everyone, on a pull-request with high visibility, which is an easy platform to get "street creds" as an ambitious engineer.
jmmv 3y ago
It’s a nightmare only if you think of the monorepo as just throwing everything in one place (aka just a technical choice). A monorepo requires org changes. It requires staffing teams to handle processes and tooling for everyone else. (And it may require something else than git… but git will work OK for reasonably large ones anyway.) I wrote about some of this here: https://jmmv.dev/2023/08/costs-exposed-monorepo-multirepo.html https://jmmv.dev/2023/08/costs-exposed-monorepo-multirepo.ht...
- mhh__ 3y ago
  FWIW "Monorepo requires people to work on it" is organisationally a bit of a cop out because everything requires this kind of work, its just a difference between each team dedicating some time to it in there little bubble (in which they do things slightly differently) versus doing it once at a larger scale centrally - this requires some investment in the form of salary but you would still spend this money in the first place, you just don't notice. Boiling frogs and all that. You'd also be surprised just how little work this actually is if you get it right, versus having to fix 50 different hacked up solutions across your company. It does put strain onto some tooling, but these days git seems to be fine well beyond kernel-scale - when you are this size you have "made it" anyway.
knallfrosch 3y ago
We have 4 interal-only projects that all kind-of depend on each other and are all rolled out at the same time: backend, frontend and two shell wrappers for the frontend (electron for windows, cordova for ipad) The total code base is still small enough for network/file system to not care (~10 devs working 10 years.) Since we're on Azure Devops, we currently have to create a pull requests for every project. If you change the naming of an API variable, you'll have to create two pull requests. You'll have to review those individually. The automatically triggered test runs will fail against the respective "old" version of each other and create noise. If, instead, we'd have a structure like this, the changes could be together: /src - backend (C#) - frontend (TypeScript) - ... Note that we're not planning to have a "shared" library or "common" editorconfig files, or changing _anything_ about code internals. Just tracking the folders in git together.
mhh__ 3y ago
All of the fastest moving, easiest to contribute to, projects I've seen use monorepos or at least understand the basic principle that things that are released together and ship together (and probably depend on eachother) should be developed together) So many of the supposed problems with monorepos (other than those of pure scaling) seem to basically boil down to "Dr Dr it hurts when I do this" For example: "What happens if two teams depend on different versions of the same internal library" - sounds like a reasonable concern no? No! This situation is fundamentally a disaster. On many levels.

I know it‘s an April‘s fool. But I don’t get this recent trend of people arguing in favor of a monorepo (at my work place, too). It’s a nightmare to handle and use. What gives?

frizlab 3y ago

Glad to see I’m not the only one thinking that.

paulgdp 3y ago

NixOS uses a monorepo and I think everyone loves it. I love being able to easily grep through all the packages source code, and there's regularly PRs that harmonizes conventions across many packages. Nixpkgs doesn't include the packaged software source code, so it's a lot more practical than what Debian is doing. Creating a whole distribution often requires changes synchronized across many packages, so it really makes things simpler. https://github.com/NixOS/nixpkgs https://github.com/NixOS/nixpkgs I think it's important to add that they both have the biggest number of packaged software and the most up-to-date software of all distributions even though they have far fewer maintainers than Debian. https://repology.org/repositories/graphs https://repology.org/repositories/graphs

bjornsing 3y ago
> Nixpkgs doesn't include the packaged software source code, so it's a lot more practical than what Debian is doing. This is the key difference. OpenWRT is a “monorepo” too, but it downloads tar balls etc of the upstream software. Makes sense. Putting the source code of the upstream software in a monorepo sounds like a nightmare…
thegeekpirate 3y ago
> I think it's important to add that they both have the biggest number of packaged software and the most up-to-date software of all distributions even though they have far fewer maintainers than Debian. Only because of https://www.reddit.com/r/NixOS/comments/zp95a2/comment/j5ko9kp/ https://www.reddit.com/r/NixOS/comments/zp95a2/comment/j5ko9... I also had plenty of issues with either packages not being available or not building, last I tried. At least with the AUR, it's generally only the latter you have to worry about ;)
- paulgdp 3y ago
  Yeah, automation in Nixpkgs is crazy and goes far beyond any other distros (that I know of). Why spend manual time when it can be automated?
viraptor 3y ago
Is nixpkgs really a monorepo as usually discussed? It's got packages, os modules, and some supporting scripts. Nix itself lives in a different place, so does the RFC planning, system artwork and a few other things. I would expect it all together to become a monorepo. > even though they have far fewer maintainers than Debian. Debian has ~1.5k contributors, nixpkgs lists >3.5k maintainers. (Although that list is not pruned over time)
- paulgdp 3y ago
  > Is nixpkgs really a monorepo as usually discussed? It's got packages, os modules, and some supporting scripts. Nix itself lives in a different place, so does the RFC planning, system artwork and a few other things. I would expect it all together to become a monorepo. I think we can say it's a monorepo of packages in this context. Not everything from the Nix ecosystem is there. It could also bundle the website, wiki, doc etc but I don't think it matter too much. > Debian has ~1.5k contributors, nixpkgs lists >3.5k maintainers. (Although that list is not pruned over time) Thanks for the info, I heard that a long time ago and never checked myself! It's probably less as you say but still probably bigger than Debian. I guess it makes sense because it's so much easier to contribute there than to Debian.

andyferris 3y ago

It probably depends on your project size, but I am one of those that find them easier to handle. What do you find nightmarish?

baq 3y ago

a hundred small repos are a different kind of nightmare. the truth is, having a large code base is just hard no matter which way you handle it. you'll end up with custom repo tooling for the monorepo or blown up CI/CD infrastructure for many small repos either way. complexity will be conserved; it can be transferred, but can't be removed.

fragmede 3y ago
baq's law of code thermo dynamics: complexity cannot be removed. it can be transferred but can not be removed. your CI/CD system will be as complicated as your repo structure isn't.
- actionfromafar 3y ago
  Saving

Muromec 3y ago

Linux kernel is a monorepo and somehow works. On the other side of the spectrum we have leftpad nonsense and latest xz thing.

dijit 3y ago

it requires a lot of discipline for sure. "It depends" is thrown around a lot; what I've seen working for large companies and on large projects (mostly AAA games, which do use a monorepo typically) is that having a single repo means your dependencies are more likely to be vendored, and updating the vendoring re-runs all tests across all services because dependencies are mapped across the whole project. Incremental build is also something that becomes more possible, rather than constantly building all source from scratch as we tend to do for smaller projects. There's a lot to be said for atomic commits, no "merge trains"[0] and things like a "common library" (that everyone ends up building in a large enough team) are just includes and not entire dependencies with all that entails (versioning, updating dependencies etc;). Having everything in one place also tends to force people to put documentation near their code instead of something else like confluence. It's pros and cons, and the pro's are kind of meek-sounding until you've experienced it. [0]: https://docs.gitlab.com/ee/ci/pipelines/merge_trains.html https://docs.gitlab.com/ee/ci/pipelines/merge_trains.html

Cu3PO42 3y ago

There are real, tangible benefits to monorepos. And real, tangible downsides, too. Like everything else, it's a tradeoff. I'm sure people advocating for them have brought up some benefits. But in case they haven't, here's an example I recently encountered at work: for an application we are developing, we needed functionality X. We knew that we'd need X in other projects, too, so we made it a library. I published it to our internal package registry and referenced it in the project. So far, so good. Turns out, feature X wasn't as well understood as we thought it was and we are still changing things around all the time. That meant: * changing the library * cutting a new release and publishing it * updating dependencies in the project and using the new feature Since this was happening much too often for what was often a one or two line change, I moved the library into the project repo and build it as part of the project pipeline. This removes so much friction around these changes, I find it makes a significant difference. Eventually, I'll move the library back into its own repository, but for now the monorepo is the right choice in my eyes.

Archelaos 3y ago
> Turns out, feature X wasn't as well understood as we thought it was and we are still changing things around all the time. If you publish something as a library for someone else, you should generally commit to supporting the public interface of that library as if it were a long-term support release. Exactly how long that should be depends on many factors, of course. But as a rule of thumb, I would recommend supporting this library version for at least two years. If that doesn't make sense, don't release it or look for a subset, where it makes sense.
- The_Colonel 3y ago
  This is exactly the friction/overhead the other person means and what monorepo works around. (but also keep in mind this is an internal library for likely a couple of internal apps, supporting BC for 2 years is in most cases unwarranted)
  - Repulsion9513 3y ago
    Monorepo doesn't "work around" it, it means you have to support everything (including migrating/BC) on the current version, instead of having to support old stuff on the old version.

frankjr 3y ago

Having to switch branches in different repos to feature-xyz, remember to build it, and then finally work/test is more of a nightmare to me. In a monorepo, you just switch to the branch once, the build system builds everything that needs building, and you are ready to go.

pheatherlite 3y ago

Most developers jump on the hype train and don't stop to think about ramifications or requirements or purpose. Having said that, monorepos have their use cases, and they help eliminate the need to have convoluted tool chains whose entire purpose is to ensure version compatibility between various components of the system... before you can even start making a line of change on the dev machine.. or some asinine docker abstraction that you must spin up... essentially, if everything is in one place (and not conceived by antisocial pranksters), you bet it's meant to be together. This makes it easier for any number of different life cycle teams to pick up a project and not waste time chasing down silly time wasting issues.

ithkuil 3y ago

The opensource tooling to handle large monorepos is just not there. The monorepo at Google with the massively distributed build system and all other tooling make it very effective to work with. You cannot just take one part of that system and expect to magically reap the benefits. The main benefit I see in practice is that you can immediately see which parts of the system are broken by your change immediately as you test your change (as opposed to waiting when integration happen later when dependencies between modules are bumped in a multi-repo)

IshKebab 3y ago
I agree it's definitely an underserved tooling area. But so is a maze of submodules which is the realistic alternative. Open source just doesn't care too much about whole-company level projects because those don't really exist in the open source world. That said, you can definitely make it work with Git & Bazel. Beats submodules by a mile.
- ithkuil 3y ago
  Oh yes. Also another thing: often people end up with the worst of both worlds: one (or two!) big monorepos plus a swarm of many little repos. Now you only pay the price of the monorepo but rarely ever notice the benefits
necrobrit 3y ago
>You cannot just take one part of that system and expect to magically reap the benefits. Yeah, specifically people only focus on the "repo" bit. Build system, PRs, history browsing, etc all get handwaved away after you stick all the code in a single repo. These are the extra hard parts though! I think if you were to properly implement "monorepos" in git world it would actually look a lot like a Github _organisation_, rather than a Github repository. Each git "repo" in the "org" would be a workspace with it's own segregated UI so that you can for example check out just that workspace, or see only that workspaces commits or issues -- but some features such as github actions workflow triggers and PRs would be able to span multiple workspaces. Github doesn't really seem to have put much thought into really supporting monorepos though. They have added some support (e.g. codeowners) to support "repo"-as-monorepo, but have also added some features that could go towards supporting "org"-as-monorepo (e.g. dependabot dependency updates and the dependency graph). But it all stops well short of a complete monorepo toolset.

surajrmal 3y ago

I struggle to understand the upside of avoiding monorepos. A lot of people think it means you can't decouple releases, modularize builds and similar with a monorepo, but that's simply not true. The efficiency at which you can refactor and upgrade your codebase cannot be understated.

IshKebab 3y ago
The main upsides I see are: * you can pretend you don't need a proper sandboxing build system like Bazel, Buck etc. and stick to Make/CMake etc. * you don't need to learn how to use sparse checkouts It basically lets you avoid learning how to solve the problems you'll inevitably run into for a little while. Not a great reason, but it is a reason.
sethammons 3y ago
every monorepo I've seen suffers from a shit CI solution. Other teams break your builds. Builds get longer and more complex. Feedback loops slow down. Engineering velocity slows down. It works at Google because they spent, literally, hundreds of millions of dollars getting it working.
- knallfrosch 3y ago
  It's not even clear whether a monorepo stretches across teams or not. I think many people are argueing about different things.

Xeamek 3y ago

> It’s a nightmare to handle and use. Why? If all Your work and knowledge is confined in one repo, there still is a way to work only on that part. Or at least there should be. But if You want/need to have access to other parts, it's much easier to use monorepo then to search trough 100 of github repos that are somehow dependent but it's not obvious in what way.

Double_a_92 3y ago

It's much nicer to have everything you could ever need in one place, instead of having to know what is in what repo. Especially when you have versions that need to correspond in the different repos...

gtirloni 3y ago

> It’s a nightmare to handle and use Quite the opposite, IMHO. Juggling dozens of PRs across many repos for a simple change is the definition of a nightmare.

sethammons 3y ago
that tells me you prematurely split something. I worked at a high scale, high available system with multiple dozens of teams, each with several repos. If we had to sync changes across repos, we joined the repos because they were, well, joined. In the early days, we had shared libraries and keeping those in sync was a pita. Then we realized we should not be doing what we were doing. The flow should be: (1) update a library and release it, preferring backwards compatible changes or a new major version; (2) code that wants/needs the new functionality updates the usage at its leisure. If you are having to keep multiple repos "in sync" with each other, yes, you picked the wrong abstraction. If the downstream repo(s) need to always be on the latest and greatest version of the library, the library code should be vendored with the calling code.
- gtirloni 3y ago
  > (2) code that wants/needs the new functionality updates the usage at its leisure. That's how you end up with infinite support costs in a large org. I think the point is that these changes are done atomically.
  - erik_seaberg 3y ago
    You can't deploy a distributed system atomically, and the closer you get the more risk you're taking with prod. The old and new versions need to coexist for at least a couple of weeks in case of rollbacks.
  - sethammons 3y ago
    that is the theory. The reality is that your team can work on fixing an issue now, but the consuming team might be able to get to it next quarter due to competing priorities. Getting multiple teams to agree to work together at the same time is much, much harder than allowing teams to update on their own schedule. You do eventually have to press the organization and deprecate the older thing. The alternative is you do the work for them - which you may or may not have the expertise for, and the other team may not even have time for the needed code review.

jillesvangurp 3y ago

Having lots of small repos also generates overhead they need to be checked out separately, tagged individually, built individually, etc. The reason that this is a bad April first joke is that the idea actually has merit. Google runs their company like this. The unthinkable bit is not doing this technically but Debian rearchitecting the way it works. Doing this with Git is a separate topic. It's probably not great for this. But mono repos at this scale are not impossible.

SOLAR_FIELDS 3y ago
There was an article by some well known CTO that hits the nail on the head for me. Essentially they said that monorepo makes sense at small scale and enormous scale (eg Google) but anywhere in between that microservices make more sense. Knowing when you are going to be at those scales is key. In any event, as has been alluded to in this thread already, any complaint about microservices vs monorepo and switching between them is almost always a tooling complaint. Companies will invest in one of these “philosophies” around code organization then won’t take the time to build the appropriate tooling to support them and then three years down the road some enterprising architect will switch from one to the other and the cycle begins anew

Shacklz 3y ago

There have already been a lot of points by other commenters, one point that I'd like to add: It allows to solve "problems of scale" with technical solutions rather than process solutions. For example: Let's say there's application app-A and app-B, and they decide they want a library lib-1 that they can share. If they are in separate repositories, this means multiple pull-requests, it means separate pipelines where the pipeline of lib-1 likely won't include the tests of the applications, it means there will be pull-requests to the library which won't immediately be integrated into the applications so that some poor sod has to take care of breaking changes down the road, etc. If they are in a monorepo, each application can set up tests that need to be fine with the library-code "as is", so any change to the library needs to work against existing application-tests. The price one pays however are pipelines that perform well - nobody wants to wait hours to get pipeline-feedback and such. A monorepo also allows ambitious folks to shine - it's easy to touch many things at once, or to touch things used by everyone, on a pull-request with high visibility, which is an easy platform to get "street creds" as an ambitious engineer.

jmmv 3y ago

It’s a nightmare only if you think of the monorepo as just throwing everything in one place (aka just a technical choice). A monorepo requires org changes. It requires staffing teams to handle processes and tooling for everyone else. (And it may require something else than git… but git will work OK for reasonably large ones anyway.) I wrote about some of this here: https://jmmv.dev/2023/08/costs-exposed-monorepo-multirepo.html https://jmmv.dev/2023/08/costs-exposed-monorepo-multirepo.ht...

mhh__ 3y ago
FWIW "Monorepo requires people to work on it" is organisationally a bit of a cop out because everything requires this kind of work, its just a difference between each team dedicating some time to it in there little bubble (in which they do things slightly differently) versus doing it once at a larger scale centrally - this requires some investment in the form of salary but you would still spend this money in the first place, you just don't notice. Boiling frogs and all that. You'd also be surprised just how little work this actually is if you get it right, versus having to fix 50 different hacked up solutions across your company. It does put strain onto some tooling, but these days git seems to be fine well beyond kernel-scale - when you are this size you have "made it" anyway.

knallfrosch 3y ago

We have 4 interal-only projects that all kind-of depend on each other and are all rolled out at the same time: backend, frontend and two shell wrappers for the frontend (electron for windows, cordova for ipad) The total code base is still small enough for network/file system to not care (~10 devs working 10 years.) Since we're on Azure Devops, we currently have to create a pull requests for every project. If you change the naming of an API variable, you'll have to create two pull requests. You'll have to review those individually. The automatically triggered test runs will fail against the respective "old" version of each other and create noise. If, instead, we'd have a structure like this, the changes could be together: /src - backend (C#) - frontend (TypeScript) - ... Note that we're not planning to have a "shared" library or "common" editorconfig files, or changing _anything_ about code internals. Just tracking the folders in git together.

mhh__ 3y ago

All of the fastest moving, easiest to contribute to, projects I've seen use monorepos or at least understand the basic principle that things that are released together and ship together (and probably depend on eachother) should be developed together) So many of the supposed problems with monorepos (other than those of pure scaling) seem to basically boil down to "Dr Dr it hurts when I do this" For example: "What happens if two teams depend on different versions of the same internal library" - sounds like a reasonable concern no? No! This situation is fundamentally a disaster. On many levels.