What is a Monorepo?
MultiRepo Vs MonoRepo
| | 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. |
Monorepos tool comparison
Compare Bazel (by Google), Gradle Build Tool (by Gradle, Inc), Lage (by Microsoft), Lerna, Nx (by Nrwl), Pants (by the Pants Build community), Rush (by Microsoft), and Turborepo (by Vercel).
There are so many awesome Monorepo tools, software and architectures.
Some enterprise-level solutions, such as Google’s Bazel and Gradle, have little to do with the front end, and the cost of getting started is relatively high, so we will not discuss them here.
|URL||Pros||Cons||Pricing||Ease of Use||Scalability||Compatibility||Dependency Management||Task Runner||Version Management|
Lerna + Yarn Workspace (Most used before)
PNPM Workspace (New package management)
Nx Vs Turborepo Vs Rush (New monorepo solution)
What’s the problem with the previous solution?
Nx and Turborepo
这里收集了一些有关 Monorepo 的视频和播客。
- Using Yarn Workspaces and Lerna with TypeScript Mono-repos - TypeScript 作者之一, Ryan Cavanaugh 在 React Europe 2018 上的演讲，介绍了如何使用 Yarn Workspaces 和 Lerna 来构建 TypeScript monorepo。
- Monorepos: Simplify Your Development Life! - 由 Kent C. Dodds 主持的视频，介绍了使用 Yarn Workspaces 和 Lerna 创建 monorepo 的基础知识。
- The Benefits of Monorepos for React Native and Web Projects - 由 Callstack 公司的 Eric Vicenti 主持的演讲，讨论了如何使用 monorepo 来改进 React Native 和 Web 项目的开发流程。
- Scaling your Codebase with Nx and Monorepos - Nrwl 公司的 Jeff Cross 主持的演讲，介绍了如何使用 Nx 来扩展 monorepo 项目，并讨论了如何处理大型代码库的挑战。
- Monorepo Patterns for Node.js and TypeScript Applications - Node.js 开发人员 Wes Todd 主持的视频，讲解了如何使用 monorepo 来组织和构建 Node.js 和 TypeScript 应用程序。
- Monorepo Architecture for Frontend Projects - 前端工程师 Karol Wrótniak 主持的演讲，介绍了如何使用 monorepo 构建现代 Web 应用程序，以及如何处理不同项目之间的共享代码和依赖关系。
Here is a curated list of articles about monorepos that we think will greatly support what you just learned.
- The One Version Rule – opensource.google
- Why TurboRepo Will Be The First Big Trend of 2022
- Build Monorepos, Not Monoliths – dev.to