Organizing Projects Into a MonoRepo with Gradle Build Management
Promote visibility and standardization across multiple teams and projects!
Combining projects into a single mono-repository has become an emerging trend in software engineering that has a wide range of benefits across the developer workflow. When you hear the term MonoRepo, you may think of the dreaded monolithic architecture with highly coupled services — but this has nothing to do with a MonoRepo! A monolithic repository is a means to consolidate multiple projects into a single codebase in order to share dependencies and standardize project workflow for any contributing team.
In this article, we are going to discuss some of the traits and tradeoffs of a MonoRepo as well as feature a real world example. We will also walk through the thought process behind standardizing the build process using Gradle. By the end, you may find that a MonoRepo is a great fit for your own projects!
MonoRepo Structures
A monolithic repository doesn’t have to abide by any strict standards. For the most part, it’s completely up to your own development teams on how they want to structure their projects. One of the main benefits of a MonoRepo is that you don’t have to transition between loading different projects into your IDE, sifting through multiple merge request (MR) locations, or have standalone projects that are responsible for shared dependencies. Instead, everything is in one place to add organization and convenience!
A simple TypeScript example
Let’s start off with an example MonoRepo consisting of two TypeScript based projects. You can use Lerna or yarn workspaces to create the MonoRepo structure and symlink the packages according to the dependencies between them. Setting up your own MonoRepo from scratch will take additional planning on how you will link your dependencies, so the tools above could possibly be a better match for you. Here’s an example MonoRepo built with Lerna and yarn:
<Your Awesome Team Name>
├── package.json
├──…
