Skip to content

My experience with a monorepo

For software projects, there exist several ways to organize its code. Usually, a project is already structured in a way that the contents of project components are isolated from each other. Shared functionality is moved into libraries that are then used by some of those components, and so on. Consequentially, one option is to also move the code of your components and libraries into their own containers - for example, their own repositories. Another option is to use only a single repository for all of your libraries and modules - a so-called monorepo.

In this article, I'd like to briefly describe my experiences with using a monorepo in different contexts. What this article is not: There are already a lot of texts that are going on about the pros and cons of monorepos, polyrepos, and hybrid models of all sorts. I do not feel the need to add another one of those, but rather mint my experience into words.

First off, a brief description of what I understand that a monorepo actually is: Monorepos are code repositories (e.g. a Git repository) that contain all of the code for one or several software projects. This not only entails the actual source code of a project (e.g. a software library for manipulating tabular data), but also

  • frontend code
  • different modules of a distributed application (for example, an event-based cloud application on AWS)
  • Infrastructure as Code modules that define how everything fits together
  • documentation
  • CI/CD definitions
  • ...

What went well

What went wrong

What was a dependency hell - and how we tried to tackle that