|                     | MultiRepo | MonoRepo   |
| ------------------- | -------------------- | --------------- |
| Pros  |  <br> - Enables better tracking of changes and version control.- Allows for independent release cycles for different projects.- Can lead to faster build times as only the necessary code needs to be built.- Reduces the risk of a single point of failure.     |  <br> - Easier **dependency management** as all code is in one repository.<br> - **One version of everything** No need to worry about incompatibilities because of projects depending on conflicting versions of third party libraries.<br> - Allows for **sharing** **of code** and resources between projects.<br> - Atomic commits across projects Everything works together at every commit. There's no such thing as a breaking change when you fix everything in the same commit.<br> - **Simplifies build and release** processes.<br> - Developer mobility Get a consistent way of building and testing applications written using different tools and technologies. Developers can confidently contribute to other teams’ applications and verify that their changes are safe.<br> - Can lead to better **code consistency** and easier maintenance.- Enables better **code reuse and refactoring**. Allows for better **collaboration** between teams.<br> - **No overhead to create new projects** Use the existing CI setup, and no need to publish versioned packages if all consumers are in the same repo.    <br> - **Hard-to-see-affected applications:** Once a developer made an update to a component library, it was hard to see all affected applications company-wide, which usually resulted in breaking features.    <br> - **Hard mode onboarding:** Newcomers struggled to find related components in these multiple codebases. |
| Cons |  <br> - Can be more complex to **manage dependencies** between different repositories.<br> - **Costly cross-repo changes to shared libraries and consumers**       Consider a critical bug or breaking change in a shared library: the developer needs to set up their environment to apply the changes across multiple repositories with disconnected revision histories. Not to speak about the coordination effort of versioning and releasing the packages.<br> - Can make it harder to **share code and resources** between projects.<br> - **Cumbersome code sharing** To share code across repositories, you'd likely create a repository for the shared code. Now you have to set up the tooling and CI environment, add committers to the repo, and set up package publishing so other repos can depend on it. And let's not get started on reconciling incompatible versions of third party libraries across repositories...<br> - Can lead to **inconsistencies** in code and maintenance issues.<br> - **Inconsistent tooling**       Each project uses its own set of commands for running tests, building, serving, linting, deploying, and so forth. Inconsistency creates mental overhead of remembering which commands to use from project to project.<br> - Can create **silos** between different **teams** working on different repositories.<br> - **Significant code duplication** - No one wants to go through the hassle of setting up a shared repo, so teams just write their own implementations of common services and components in each repo. This wastes up-front time, but also increases the burden of maintenance, security, and quality control as the components and services change. |  <br> - Can be difficult to set up and maintain.- Can lead to slower build times as the entire repository needs to be rebuilt.- Can make it harder to track changes and version control.- Can create a single point of failure.               |
| Use Cases  |  <br> - Large-scale projects with **multiple independent** projects.- Projects with **complex dependencies or different release** cycles.- Teams with independent developers working on different codebases.                |  <br> - Large-scale enterprise projects with **multiple interdependent** projects.- Projects with **shared dependencies** or code.- Teams with multiple developers working on the same codebase.      |