This article looks at how Multirepo and Monorepo code management are based on the philosophy of “divide” and “join” respectively

Multirepo

Multirepo (one-repository-per-module) is a relatively traditional approach. As the name implies, it advocates dividing projects into multiple code bases by modules. Through scientific decomposition, each REPO can be independently developed and tested to improve development efficiency

During the development of Multirepo, it is very important to avoid excessive refinement. There must be a mechanism to keep track of the situation and monitor the health of the development environment

The advantage of Multirepo

  • flexible

Each REPO has the flexibility to choose development tools, environment configurations, and so on

  • security

Natural authority control, release online to other projects without impact

Multirepo disadvantage

From the management mode, we can easily see that this code management mode has the following shortcomings:

  • Code reuse

Code reuse becomes an issue when common components, common functions, or common configurations (such as various Configs) are involved across multiple REPOs. You may have thought of the following solutions:

  • Copy related code to target directory? – High maintenance cost

  • Extract common logic and send NPM package? Change -> release -> High installation cost

  • Version management

Versioning of dependent packages is sometimes a particularly esoteric problem in the context of MultiRepo development. For example, at the beginning a toolkit version was v1.0.0. There were many projects that relied on the toolkit, but at some point the toolkit shipped a break change version that was completely incompatible with the original API. In fact, some projects do not upgrade this dependency, resulting in some unexplained errors

When there are many projects, it is easy to have this dependency update situation. This is another pain point

  • Development and debugging

When multiple projects are involved in development, you may need to open multiple IDE Windows for switching development, and although you can use NPM Link mode for debugging, but manual management of many link operations is very inconvenient

  • The project construction

Because among MultiRepo, each project workflow is fragmented, so each project requires a separate configuration, configuration, development environment, CI process release process, configuration, deployment, etc., and even each project has its own separate set of scaffolding tools, however, in many cases, these projects there is a big part of repetitive construction and logic, Maintenance costs are also high when specifications for building, deploying, and publishing are inconsistent across projects.

monorepo

Monorepo’s idea is strict unity, with multiple projects in one warehouse. The more well-known ones like Vue3, Babel, and NPM7 are all managed in Monorepo mode. The common directory structure of Monorepo is as follows:

- packages
  - project1
    - src
      - index.ts
    - package.json
  - project2
    - src
      - index.ts
    - package.json
  - project3
    - src
      - index.ts
    - package.json
- lerna.json
- package.json
- tsconfig.json
Copy the code

advantage

  • Unified workflow

The first is workflow consistency. Because all projects are in one repository, it is very easy to reuse. If there is a dependency code change, the project using the dependency will immediately feel it. And all projects are the use of the latest code, will not produce other project version update not timely situation, for development and debugging have brought convenience

  • Reduce infrastructure costs

The second is the reduction of project construction cost. All projects reuse a set of standard tools and specifications without changing the development environment. If a new project is added, existing infrastructure process can be directly reused, such as CI process, construction and release process. It requires fewer people to maintain the infrastructure for all projects, and maintenance costs are greatly reduced

  • Improve teamwork efficiency

Moreover, teamwork is also more easy, on the one hand, everyone is in a warehouse development, can easily share and reuse code, convenient retrieval program source code, on the other hand, the git commit history also support to function as a unit for submission, to submit a feature, need to change several warehouses, multiple commit, You now commit only once, simplifying the COMMIT record and facilitating collaboration

disadvantage

Monorepo’s shortcomings are also obvious

Volume problem

Because all code is under one REPO, this results in the size of the entire REPO becoming larger as the project becomes more complex. It sounds like a nightmare when someone in a large company wants to change a small style in a project and needs to pull tens of gigabytes of repO locally

Of course, this problem can also be optimized with the help of some mechanisms provided by Git itself. If you are interested, you can learn about sparse checkout and shallow cloning

Permission problems

Permissions are open in Monorepo mode. Code security, document security, is a serious consideration. This aspect, if not handled properly, can be disastrous for the entire team and project

Version control

Repositories become too large, and versioning technology becomes a challenge. Because the Git community recommends using more and smaller code bases, Git itself does not lend itself to a single large code base

conclusion

Monorepo and Multirepo are both ways of managing organizational code, and the core difference between the two comes down to what philosophy do you believe enables teams to work most effectively together (diversity vs. centralized management), so the question is, which is better? Again, “there is reason”, tools are used to serve production, the more effective solution to the current problem is better

Afterword.

To implement Monorepo in actual scenarios, a complete engineering system is needed to support it, because project management based on Monorepo is not just about putting the code together, but also needs to consider inter-project dependency analysis, dependency installation, construction process, test process, CI and release process and many other engineering links. At the same time, performance problems should also be considered when the project scale reaches a certain level, such as incremental build/test, CI execution on demand, etc., while achieving comprehensive engineering capability, performance problems should also be taken into account

Therefore, it is very difficult to customize a complete set of Monorepo engineering tools from scratch. However, the community already provides some mature solutions that we can customize or use directly for some upper-level solutions.

Among them, the lower-level schemes, such as Lerna, encapsulate the basic functions of Monorepo such as dependency installation and script batch execution, but there is no set of tool chain for building, testing and deployment. The overall function of Monorepo is relatively weak, but when it is used in business projects, it is often necessary to encapsulate top-level capabilities based on it. Provide support for comprehensive engineering capabilities.

Of course, there are also some integrated Monorepo solutions, such as NX and RushStack, which provide the full process capability from initialization, development, build, test to deployment. There is a relatively complete Monorepo infrastructure, suitable for the development of business projects directly. However, because the various internal processes and tool chains of these top-level solutions have been very perfect, it is basically not feasible to customize based on these solutions, and the cost of adaptation and maintenance is too high

Refer to the article