Adopting Monorepos

This article is a -text based- on a talk by OpenForge for Ionic Enterprise App Summit

We hear about it all the time: teams have built their applications as mono repositories and have had killer success across the board. Businesses benefit, technology benefits, performance improves—you name it and we've seen it! However, you may think monorepos won't work for you. You already have your infrastructure set up, and it would be way too much effort for your product team to migrate over, right? Wrong.

If you are a software lead with an existing product looking to learn how to transform your product and your team to a monorepo, then this presentation is for you. OpenForge will present to you real strategies and exact implementations for converting your current team into a monorepo team.

💡 Powered by:

Jedidiah Weller CEO & software guru at OpenForge

Fernando Del Olmo Software Engineer at OpenForge

Maria Jose Mendez Software Engineer & Architect at OpenForge

First of all, we are going to describe what is a Mono Repository:

A monorepo (mono repository) is a single repository that stores all of your code and assets for every project.

Here you can find some benefits of mono-repos:

• Productivity & Time Savings

• Improved code sharing

• Enhanced cross-team collaboration

• Ability to easily assign ownership

• Decreased overhead costs (and headaches)

• Enforce code ownership.

And as you can start thinking, there is not information about HOW you are gonna be able to migrate your team to a monorepo architecture, thankfully we did it, and we had some lessons learned along the way that want to share with you.

First we detected our first symptoms:

1. We were having more than 1 repo to a single product, we used to have a frontend, a backend and a API repositories.

2. Of course, since we were building software towards a single product, we noticed we use the same services, data models and functionality in all the 3 repositories.

3. When having to maintain 3 different repositories, change a single data model could be a nightmare if you are not used to share code between your applications

4. Having 3 different repositories with almost the same modules and packages were not the best way to reuse and save time when building and deploying.

Here is how our old folder structure looked when we first attempted to create a mono repo:

And here, you can see our new folder structure, and its right away benefits:

• Readability

• Scalability

• Less maintenance

• Visibility

• Standardization

After we learned how to do it, we discovered a few things you will take into consideration when migrating a team.

Step #1 - Resource Allocation

• Preparation

• Work the with team to identify Libraries

  • Applications, Features, UI, Util, Data-Access, etc.

• Assign Code Ownership

• Schedule Refactoring

• Schedule Cross-Team collaborations

Step #2 - Creating the Repo

• Initialize repo using Nrwl’s NX Guidelines

• Create skeleton of the

  • Applications

  • Libraries

    • Data-access

    • Features

    • UI

    • Util

  • E2E

• Re-review your initial architecture!

Step #3 - Setup Enforcements

This is our basic recommendation to enforce quality code:

• README

• ESLINT

• StyleLint

• Prettier

• TSConfig

• Commitizen

• CI /CD

• Husky

Step #4 - Naming Conventions

THIS... this is a very important step, you really need to sit down and discuss the best naming convention that works for your company and team.

• Create initial libraries with NX Generate

• Create initial components with NX Generate

• Create all initial blank UI Components

• Re-review naming conventions BEFORE adding any logic

• Review as a whole, per library / application.

Step #5 - Migration!

• Feature Owners start migrating components first

• Start with Libraries

• Then Applications (front-facing)

• Then Server Apps

We hope you enjoy this small guide about monorepos, If you want to know more, please see our recorded talk here:

Leveraging Mono Repositories for Enterprise Projects

And, don't forget to follow us