Purported Advantages of Monolithic Repositories (Monorepos)

[aaronjensen]

https://github.com/aaronjensen/software-development/blob/master/monorepo-advantages.md

[doughtnerd]

Having worked in both monorepo & multi-repo environments, I can see the appeal of each but more often than not, teams try to build a monorepo without understanding the tooling that needs to be in place to do it properly. You mention it but the tooling that's been built to ensure monorepos only run tests (or builds, etc) for only changed packages and their efferents is quite complex. Additionally, special expertise is often required to maintain the monorepo - for instance, I worked in an org where their principled engineer's only job was to maintain their bazel monorepo.

One thing I really do enjoy about monorepos however, is the tooling some monorepo frameworks (like NX) have around dependency graphing. I'm likely ignorant of other tooling that exists for a similar function but one thing I find difficult about exploring Eventide's repos is discovering which modules are used where (without looking at a gemfile). Another aspect that can be quite helpful is there's sometimes tooling for boundary enforcement of the modules within the monorepo (i.e. I can configure a library module to only be importable by specific types of modules).

Regardless of the approach, the principles I care about are modularity, code shareability, and boundary enforcement. I do appreciate that the fad of monorepos has lead to orgs thinking about these things a little more carefully but am disappointed about how overcomplicated it's become and how orgs ignore tools that already exist to gain all of the benefits of a monorepo without the additional complexity.

[aaronjensen]

One thing I really do enjoy about monorepos however, is the tooling some monorepo frameworks (like NX) have around dependency graphing

I've played with doing this manually using graphviz. It wasn't great.

I find difficult about exploring Eventide's repos is discovering which modules are used where (without looking at a gemfile)

The Gemfile and the Gemfile.lock are the best ways. I've found that in 3-4 years of working in this style the only time it's necessary is when I'm going to be updating a dependency, I need to know where I need to update it. That usually involves searching Gemfile.lock in deployment projects. We don't commit them in package projects.

Another aspect that can be quite helpful is there's sometimes tooling for boundary enforcement of the modules within the monorepo

In Ruby, this is Packwerk, and it's something I consider to be a palliative. It's something that failing projects use to try and get out of the hole they've dug themselves into without yet really understanding what life looks like outside of the hole. It's akin to digging sideways once you are already in the hole. I don't believe this type of tooling is necessary at all. Actual packages (in Ruby, Gems) solve this without the additional complexity of the tooling and the delusions that go along with using it.