Breaking up a monolith can be a daunting task. Oftentimes a monolith gets broken up into many repos, and sometimes into a monorepo.

But, here's the problem I have with the term monorepoo.

Monorepos are NOT monoliths!

I recently heard a talk by Marcel Cutts called... MonoRepos for the Masses. It's a great talk about the history of monorepos and big companies using them. I LOVED that talk. Definitely give it a listen.

Mono, obviously is a word that comes from latin which means, "one". The fact that the word "mono" is used in both monorepo, and monlith, tends to lend itself to a lot of confusion.

MonoLITH

First, off, monolith in an of itself might not be a bad thing for your company/team. There are a lot of companies, particularly startups, that have done great things with monoliths. In fact, Martin Fowler notes that most microservice architectures that started as microservice vs starting as a monolith and getting broken up, tend to result in bad architectures.

bliki: MonolithFirstGoing directly to a microservices architecture is risky, so consider building a monolithic system first. Split to microservices when, and if, you need it.Martin Fowlermartinfowler.com

However, I think the drawback starts to happen when you get to a point where hundreds of folks are constantly working and committing code into it. You can very easily end up with the https://exceptionnotfound.net/big-ball-of-mud-the-daily-software-anti-pattern/Big Ball of Mud anti-pattern. A monolith can be come a castle housing your most precious of code; an impenetrable fortress surrounded by a crocodile filled moat of unforgiving technical debt.

If you're not careful, very tight coupling between different parts of the monolith can make it impossible to ship one part of the application without shipping the whole thing, and make it very difficult to refactor into smaller pieces as well.

MonoREPO

Here's where things get interesting. So, yes, the word "mono" exists in both places, but that's not to say that they do and serve the same exact purpose. There are a lot great reasons to keep all of your code in a single repository, just like you would in a monolith.

The distinction however though is that, unlike a monoLITH, a monoREPO is usually just a lot of packages sharing the same code base. Some of these packages are dependent on other packages sure, but in no way does the monorepo have to ship all at once as is the case with a monolith. Nor does it mean that the repo is a big ball of mud with muddied concerns, and tight coupling.

It's for the above reasons that the term monorepo should be replaced by "megarepo".

s/mono/mega/

I propose we call them "megarepos" going forward. Too many people conflate the term "monolith" with "monorepo". Let's fix it. #divops

— Jonathan Creamer (@jcreamer898) October 31, 2019

The mono/mega repo should be defined as...

A bunch of packages in once place with shared tooling to facilitate collaboration, increase productivity, and create a single culture.

A few highlights from using a megarepo are:

• Consistent build tooling
• Less context switching
• Much MUCH easier to update shared code
• Easier to affect change across the platform
• Code reviews are centralized

In the wonderful world of a megarepo, you can in fact see the forest for the trees. Meaning, you get a sense of what all is available to you as a member of a larger organization. If the packages in your megarepo have tooling which enables them to be easily tested, shared, and used as isolated units, you end up in a world where your application itself is the component library. Disparate packages which, in a multirepo setup, might become difficult to discover are easy to find and work with as they are written, tested, and documented all in the same place.

The megarepo often has a group of shared dependencies as well. In the case of a frontend project with a React toolchain, the base level React version might be shared across packages, or there maybe shared components which have a shared version across packages. This is not a drawback of a mega, it's a plus! Now you get to live in a world where an update to a shared package can all at once have every single dependent package run a test suite to verify that it didn't break. This makes it so much easier to maintain consistency across your entire application.

Nothing is without its negative sides of course. There is no such thing as a silver bullet, and in no way is a megarepo the right thing for every team, in every situation. Just like any tool, it should be thought out extensively before put into practice. One of the biggest obstacles in working this way is, it requires a good deal more tooling to work with. So, if you're at a company where there's no team managing the platform of the megarepo itself, it can be a difficult task to maintain it.

That being said, when you do have a team dedicated to writing tools for the megarepo, it can be a fantastic option, and I have to give credit to Ben Ilegbodu, and maybe Kyle Welch for helping me come up with the term.

I'll give you microapps but megarepos was me. My how quickly revisionist history happens after leaving!

January 2020: "Ben who???"

— Ben Ilegbodu 🏀 (@benmvp) October 31, 2019

Conclusion

A move away from the word monorepo will hopefully convey the fact that even though code might share the same repo, it is not in any way, a monolith.

I love the idea of creating a single culture, it was a great take away from Marcell's talk.

So, how about going forward, rather than talking about monorepos, we talk about megarepos, and how much benefit they can bring to a large team.

// TODO: write a post about how to implement one

How to successfully implement a megarepo · Issue #1 · jcreamer898/blog-post-ideasNeeds to discuss options like Bolt and Lerna. Talk about the build tooling.jcreamer898GitHub

Any other topics you want to hear more about?

Add an idea.