1. 17
  1.  

  2. 13

    This argument reminds me of the quote about microservices: “You don’t need to introduce a network boundary as an excuse to write better code.” Likewise, I don’t think you need to introduce a repository boundary as an excuse to write better code.

    1. 9

      This is really interesting to me because it directly states a thing the other monorepo articles only implied: The author imagines a single repo as the “natural state”, and modular repos as “a thing that happens to a monorepo”.

      I’m starting to think that your opinion on monorepos depends on your personal experience:

      • work at a megacorp where monorepi were your first real DVCS experience: this is the “natural order”, and modular repos are “breaking up the repo”
      • work in modular repos, then watch a well-meaning autocrat try to merge them all into a centralized authority: the monorepo is “asserting control” by an unwelcome outside group
      1. 4

        Great point. I think the answer obviously falls somewhere in the middle - monorepos work sometimes, polyrepos work sometimes. The real answer is that making things work trumps other considerations, so if a monorepo removes more obstacles than it creates for your team, then a monorepo is a good answer for you.

        These same sorts of arguments crop up in lots of other situations as well; *Framework X is better than Framework Y” is a classic, but usually the answer is really that each framework solves things slightly different and you should use the one that solves things for your team in a reasonable way. When you get into monolithic discussions, there isn’t always one answer that is always going to be the best answer, because each project has more things to consider than is possible in the length of one article.

      2. 4

        The major issue not addressed is deployment. This is where the benefits of a monorepo really kick in, but where most deployment systems break down. For example, say your system has 4 services, and they communicate with structures defined in a well defined location in the repo. Great, now you can change the data structure, and all the services that use it can be changed, compiled and tested all at once. Now, imagine that the change only affects 2 services, you want a way to deploy only those two services, simultaneously and safely, so that an old version of service1 never talks to a new version of service2. That’s a bit of a headache.

        1. 1

          I don’t see why this is a headache in a way unique to monorepos.

        2. 3

          The main issue with sub-repos is that you never know which commit of which branch of one repo is compatible with another commit of another repo. In theory things should be versioned or there should be tooling to manage all this, but often it’s not done, and I see the same problem over and over again in various projects I worked on. Manager splits things into sub-repos and considers the job is done, “things are organised now”, except they are not.

          With monorepo it’s much simpler - the dependency management between modules is built-in - you can check any commit of any branch and it just works. And as he mentioned in the article, splitting things up into directories is perfectly reasonable and code review is there to ensure that no-one is making a mess.

          I think it makes sense to use sub-repo for things that are generic, independent libraries, basically code you could release as open source (I guess React for instance is not part of the Facebook monorepo).

          1. 1

            Good article, thanks! I don’t disagree with the points made, though personally I’m much more in the “use what works for you” camp overall.

            I’d like to see a bit more of the working behind this, though:

            I think it’s clear that borders can only take away from your ability to perceive opportunities to use abstractions or to unify code

            Surely the abstraction in any modular project (ideally) is the border? Which is to say, any client of your service or library understands and uses the API that you present without having to know or care what goes on behind the scenes.

            1. 1

              It’s funny that the author thinks monorepos work best at small scale & problems only show up at large scale. The single largest monorepo is almost certainly Google’s (over 2 billion LoC in ~9 million source files) and it works just fine.