Why is Monorepo more and more inseparable from modern front-end engineering?

With the increasing complexity of front-end engineering, certain businesses or tool libraries usually involve many warehouses, then over time, the development of multiple warehouses will become more and more Monorepo . This article mainly Monorepo the concept of MultiRepo , the drawbacks of Monorepo , the benefits of Monorepo the landing of 0616ab7c779103 to understand and learn Monorepo . There will be thought questions at the end of the article, and everyone is welcome to discuss.

What is Monorepo ?

Monorepo is actually not a new concept. In the field of software engineering, it has a history of more than ten years. Conceptually, it is easy to understand, that is, to put multiple projects in a warehouse, in contrast to the traditional MultiRepo model, that is, each project corresponds to a separate warehouse for decentralized management.

Modern front-end engineering has become more and more inseparable from Monorepo . Whether it is business code or tool library, more and more projects have adopted the method of Monorepo for development. Google would rather put all the code under a Monorepo project. The source code of well-known open source projects such as Vue 3 , Yarn , Npm7 Monorepo in the way of 0616ab7c779199.

Generally, the directory of Monorepo packages are multiple sub-projects stored in 0616ab7c7791c2, and each sub-project has its own package.json :

├── packages
|   ├── pkg1
|   |   ├── package.json
|   ├── pkg2
|   |   ├── package.json
├── package.json
 

So Monorepo have that makes everyone admire it so widely?

The pain of MultiRepo

If you want to know Monorepo , you must first understand the pain points of the previous development method.

In the previous traditional method MultiRepo , each project corresponds to a separate code repository. I developed it in this way before, and I really felt the many drawbacks brought about by this way. Now I will share with you one by one.

Code reuse

When maintaining multiple projects, some logic is likely to be used multiple times, such as some basic components, tool functions, or some configurations. You may think: Or you can directly come over copy ! But there is a problem. If these codes appear bug , or need to make some adjustments, they have to modify multiple copies, and the maintenance cost is getting higher and higher.

How to solve this problem? A better way is to extract the common logic code npm package. Once you need to change it, you only need to change one code, and then publish will do.

But is this really solved perfectly? Let me give you an example. For example, if you introduce the 1.1.0 package of version A , there is a problem with a tool function, you need to do these things:

• To modify the code of a utility function
• Release 1.1.1 version of the new package
• Install the new version A .

It may just be a change of one line of code, which requires so many processes. However, in the development stage, it is difficult to guarantee that bug is not guaranteed. If there is a button that needs to be changed, and the above process needs to be repeated... Stop and think about it, these repeated steps are really necessary NS? We just want to reuse the code. Why is it so complicated to modify the code every time?

The above-mentioned problem is actually a MultiRepo . Because of the fragmentation of different warehouse work areas, the cost of reusing code is high, the development and debugging process is cumbersome, and it makes people feel crazy even when the basic library is frequently changed. , The experience is very poor.

Version management

In MultiRepo , the version management of dependent packages is sometimes a particularly metaphysical problem. For example, the first toolkit version is v1.0.0 , and many projects depend on this toolkit, but at some point, this toolkit released a break change version, which is completely incompatible with the API In fact, some projects did not upgrade this dependency, resulting in some inexplicable errors.

When there are too many projects, it is easy to happen that this dependency is not updated in time. This is another pain point.

Project infrastructure

Because in MultiRepo , the workflow of each project is fragmented, each project needs to configure the development environment, configure the CI process, configure the deployment release process, etc., and even each project has its own set of scaffolding tools.

In fact, it is easy to find that many of the infrastructure logics in these projects are duplicated. If there are 10 projects, you need to maintain 10 infrastructure procedures. Not to mention the logic duplication, there are construction, deployment and release specifications between each project. In a unified situation, it is even more troublesome to maintain.

Branch management

In MultiRepo , if each iteration in the group undertakes a lot of business requirements, the projects involved may be as large as five or six. Some business needs go to the development branch, some business needs go to the feature branch, and some are being tested. Or transfer, some hot fixes, etc. The branch management of so many projects is particularly complicated and problems are prone to occur.

Monorepo earnings

MultiRepo the pain points of 0616ab7c77943f, I believe you can probably understand why the technology of Monorepo Now let's analyze in detail what Monorepo to modern front-end engineering.

The first is the consistency of the workflow. Since all projects are placed in a warehouse, it is very convenient to reuse. If there is a dependent code change, then the dependent project will be immediately aware of it. And all projects use the latest code, and there will be no case that other project versions are not updated in time.

The second is the reduction of project infrastructure costs. All projects reuse a set of standard tools and specifications, and there is no need to switch the development environment. If new projects are connected, the existing infrastructure processes can also be reused directly, such as CI process, construction and Release process. In this way, only a few people are needed to maintain the infrastructure of all projects, and the maintenance cost is greatly reduced.

In addition, teamwork is easier. On the one hand, everyone is developing in a warehouse, which can easily share and reuse code, and facilitate the retrieval of project source code. On the other hand, git commit also supports submission by function. For the submission of a certain function, several warehouses need to be modified and multiple commit submitted. Now it only needs to be submitted once, which simplifies the commit and facilitates collaboration.

The landing of Monorepo

If you have never been in contact with Monorepo , you may be confused here: I just said so many Monorepo , but I still don’t know how to use it! Is it enough to just move all the code to one warehouse?

Of course not. To land Monorepo in actual scenarios requires a complete engineering system to support it, because Monorepo by no means just 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 issues after the project scale reaches a certain level should be considered. For example, the project construction/testing time is too long and needs to be incrementally built/tested, CI executed on demand, etc. Etc., while realizing comprehensive engineering capabilities, performance issues also need to be taken into account.

Therefore, it is very difficult to customize a complete set of Monorepo However, the community has provided some more mature solutions, we can use them for customization, or directly use some of the upper-level solutions.

Comparative example embodiment wherein the bottom Lerna , encapsulates Monorepo basic functional dependence installation script batch execution, etc., but without a build, test, deploy tool chain, the overall Monorepo function is relatively weak, but to use In business projects, it is often necessary to encapsulate top-level capabilities based on it to provide support for comprehensive engineering capabilities.

Of course, there are also some integrated Monorepo solutions, such as nx (the official website is really good, and there are many video tutorials), rushstack , which provides full process capabilities from initialization, development, construction, testing to deployment, and a set of comparisons The complete Monorepo infrastructure is suitable for direct business project development. However, since the various internal processes and tool chains of these top-level solutions are already very complete, it is basically not feasible to customize and maintain the cost based on these solutions.

Instance

When I built the React business component library, I used lerna manage the multi-package repository, and the package was released separately, because only certain business components will be used in the project, and changes in business requirements will only change a certain business component, so it cannot be like a general component library. Use all releases.

Reference: Build a react business component library from zero to one

Summarize

All in all, Monorepo is to turn independent projects into a unified project, solve MultiRepo , and improve R&D efficiency and project quality. Finally, I still have a question. Monorepo solving the previous pain points with 0616ab7c7795dc, what new problems have arisen? Can these problems be solved? Welcome everyone to discuss together in the message area.

Reference

[1] lerna: https://lerna.js.org/

[2] nx: https://nx.dev/latest/react/getting-started/getting-started

[3] rushstack: https://rushstack.io/