Introduction

The choice of repository structure plays a pivotal role in shaping the efficiency and scalability of your projects.
A monorepo lets you break your monolithic codebase into well-defined domains or bounded contexts.

In this article, we will outline some benefits of monorepo for your product.

Shared codebase

The workflow to share code among multiple repositories is like this:

• You create a pull request in repo A
• you await the review of your changes
• you merge your changes in repo A
• you make a release to repo A
• you update repo A dependency on repo B

You need 5 iterations to update shared code among polyrepos.
This is a workflow in a monorepo:

• You create a pull request in monorepo
• you await the review of your changes
• you merge your changes in monorepo

In a monorepo, you only need 3 iterations.
However, you earn much than that, you make sure your code will work at first.
When updating a code in repo A, you can't share the changes will be enough for the repo B use case. You could need to go back and forth until you get it right.

New package vs new repo

It is simpler and easier to create a new package inside a monorepo than to create a new repo.
The new package will reuse all the infrastructure already in place. Linter, tests, CI/CD, automation.
The new repo will need to be created from a boilerplate that is probably outdated.
Most developers will avoid creating a new repo as it requires a lot of effort.

Unified Tooling

A monorepo lets you unify your tooling and codebase patterns.
You can have a single lint config, you can have a single CI/CD config. As a result, you have a more unified codebase.
You can use the same test and build configs among packages.

Centralized dependencies

You can keep all your dependencies updated in a monorepo. No need to update the same dependency in many repositories.

Bounded Contexts

You can use packages to provide a public API for each domain or context of your product. And keep the private API unexported.
This will make sure you don't couple your code too much.

Read more about DDD on monorepos here: Domain Driven Design using a monorepo

Refactoring and codemods

A monorepo makes it easy to refactor and apply _codemods _(transformation over AST) to reduce legacy code.
You don't need to apply the same refactor in many repos, just in a single repo.

In the final analysis

A monorepo lets you add more structure to your codebase as you grow. You can start your monorepo with one single package, and add more packages as needed.
You can have one package for each domain.
You can have one package for each service or lambda.
You can have one package for your design system.

How does your monorepo looks like?

Woovi
Woovi is a Startup that enables shoppers to pay as they like. To make this possible, Woovi provides instant payment solutions for merchants to accept orders.

If you want to work with us, we are hiring!

Photo by Amélie Mourichon on Unsplash