Monorepos: From Discovery to Deployment - A Developer's Journey

My first introduction to the concept of a monorepo came when I was search for an alternative to Create-React-App. One option that had potential and a lot of support was Nx, which was (and still is) described and a build system with "First Class support for monorepos". I didn't fully understand the concept of a monorepo at the time beyond that "mono" meant one and "repo" obviously referred to a GitHub repo. So it fell by the wayside in my mind.

A New Problem

A few months later, I started investigating a new problem my team and I were struggling with. For some context, my team and I manage the frontend of product suite. And like many product suites, the webapps follow the same design system and make use of many similar components. Even "under the hood" they all have the same tech stack.

The problem with this methodology (as I'm sure you have realized) is that of duplication. This problem of duplication can be split into 3 parts:

1. Dependency maintenance must be repeated on each webapp separately and then tested and deployed
2. It’s too much of a hassle to maintain code sharing libraries, "It’s just easier to implement it myself", leading to duplicated code.
3. Creating new webapps within the suite results in another identical project that adds to the above problems

Solution Requirements

The solution to this problem is to implement a methodology that makes dependencies and other shared code more accessible to multiple features. This solution would also need to be extendable, so that any new features can inherit any already existing boilerplate code or shared components.

Research

And so the research began... ooh, that sounds to episodic. I explored a number of popular options including; shared config modules, project templates, code generators and shared git submodules are all fine recommendations. But none of them were able to fulfill all the requirements.

Monorepos though, practice consolidating all apps and libraries in one workspace/codebase/repository, simplifying dependency management and ensuring code consistency. With the shared components in one place, representing a single source of truth, any updates to them are synchronized across all apps and libraries. Any new apps will also inherit existing project configurations thereby streamlining development and maintaining code coherence.

Let's Get Going

Hold up now, "One does not simply implement a monorepo". This is a fundamental change to your development architecture and has more far reaching effects than just solving this problem I've described. Each aspect of how you want to implement a monorepo needs to be investigate and tested, proof of concepts should be built to demonstrate that the tools or techniques you want to use are beneficial to your product and team. I say this not to dissuade you from starting, but to make sure each aspect is implemented deliberately, because once you start down the road of a new methodology, it can be harder to backtrack if you encounter issues.

Additionally, having a development plan can help to sell the idea to other team members, leaders and most importantly, sponsors.

This series will cover my journey of migrating from a multi-repo to a monorepo architecture, as well as the research I did, questions I asked and challenges I faced.

Up next

The next part will cover a short intro of what monorepos are, pros and cons, features and challenges. I'll also include a few Q&As from my team about this approach.