| The argument of why monorepos suck seems to largely rely on "CI Sucks" in this article. But I beg to differ.
Monorepos only work in combination with a build system that tracks dependencies carefully. I contribute a lot to Nixpkgs, which is a monorepo
with almost 50000 subcomponents [1], but because the
build tool and CI track changes through hashes, changing
a package only triggers rebuilds of other packages that depend on it and builds are super quick. It accomplishes this by heavily caching previous builds and sharing those between all builders. No, monorepos are not going to work with a CI and build tool that always builds everything from scratch and does no caching. Instead, you should pick the right tool for the job, and go with a build system like Nix, Buck, Bazel or Please which were designed with monorepos in mind. I think the second point the author makes, but only very briefly, is way more important to look at.
Is git itself up to the job for such large repositories?
One problem I've started running into in nixpkgs is
that `git blame` takes considerable time to even execute, due to the enormous volume of commits in the repository. I would love to see a version control system that is optimised for storing lots of loosely connected components, and has better support for partial checkouts. I haven't found it yet, and I would love to hear what others are using for this. I hear facebook has some modification of mercucurial. And Google probably created something themselves in-house. But is there anything open-source that supports these workflows at scale? [1] https://repology.org/repository/nix_unstable |
YAML in and of itself is not the easiest thing to parse when you have multiple layers of nesting and a lot of lines.
I don't really want to see what a CircleCI config would look like for Nixpkgs.
Once you get to the point of scaling your CI you're looking at tailored infrastructure to make sure you're only building what needs to be built.