As front-end engineering becomes more and more complex, some businesses or tool libraries often involve many warehouses. As time goes by, the disadvantages of multiple warehouse development become more and more obvious, and a new project management approach — Monorepo emerges. In this paper, the concept of Monorepo, the disadvantages of MultiRepo, the benefits of Monorepo and the landing of Monorepo from these perspectives to understand and learn about Monorepo, there will be questions at the end of the article, welcome everyone to discuss.

What is a Monorepo?

Monorepo is not a new concept, it has been around for more than a decade in software engineering. It is conceptually straightforward to put multiple projects in a single repository, as opposed to the traditional MultiRepo model, where each project has a separate repository for decentralized management.

Modern front-end engineering has become increasingly inseparable from Monorepo, no matter business code or tool library, more and more projects have adopted Monorepo way to develop. Google prefers to keep all the code under a Monorepo project. The source code of Vue 3, Yarn, Npm7 and other well-known open source projects is also managed by Monorepo.

The Monorepo directory is shown below, with multiple subprojects in Packages, and each subproject has its own package.json:

├ ─ ─ packages | ├ ─ ─ two packages pkg1 | | ├ ─ ─ package. The json | ├ ─ ─ pkg2 | | ├ ─ ─ package. The json ├ ─ ─ package. The jsonCopy the code

What is the magic of Monorepo that makes it so popular and popular?

The pain of MultiRepo

To understand the advantages of Monorepo, you first have to understand the pain points of previous development methods.

In the traditional MultiRepo approach, there was a separate repository for each project. I’ve developed in this way before, and I’ve really felt the drawbacks of this approach. Now I will share with you one by one.

1. Code reuse

When maintaining multiple projects, some logic is likely to be used more than once, such as basic components, utility functions, or configurations. You might think: Why not just copy the code directly? The problem is that if the code becomes buggy or needs to be tweaked, it becomes more expensive to maintain.

So how do you solve this problem? A better way is to extract the common logical code and publish it as an NPM package. If you need to change it, just change one piece of code and publish.

But is this really the perfect solution? For example, if you are introducing package A 1.1.0 and A utility function is broken, you need to do these things:

    1. To modify the code of a utility function
    1. release1.1.1Version of the new package
    1. Install the new version of A in the project.

Maybe it’s just one line of code that needs to go through so much. However, the development stage is difficult to ensure that there is no bug, if there is a button to change a style, and the need to re-walk the above process…… Stop and think, are these repetitive steps really necessary? We just want to reuse the code, why is it so complicated to change the code every time?

The above problems are common in MultiRepo because of the fragmentation of the different warehouse workspaces, resulting in high cost of reusing code, a cumbersome development and debugging process, and even a frustrating experience when the base library changes frequently.

2. 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.

3. Project infrastructure

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

In fact, it is easy to find that the logic of many infrastructure projects in these projects is repeated. If there are 10 projects, it is necessary to maintain 10 infrastructure processes. Despite the logic repetition, the construction, deployment and release specifications of each project cannot be unified, which makes maintenance more troublesome.

The benefits of Monorepo

After explaining MultiRepo’s pain points, you can probably understand why Monorepo was born. Now let’s take a closer look at the benefits Monorepo brings to modern front-end engineering.

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 using the latest code, there will be no other project version update in a timely manner.

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.

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.

Monorepo landing

If you have never been involved in the development of Monorepo, you may be wondering: AFTER all the benefits of Monorepo, I still don’t know how to use it. Do you just move all the code to a warehouse?

Of course not, in the actual scene to be born Monorepo, need a complete set of engineering system to support, because Monorepo based project management, is not only the code together can, also need to consider the project dependencies between analysis, depend on the installation, the build process, testing process, CI and release process, and many other engineering link, 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.

There are also integrated Monorepo solutions such as NX and RushStack, which provide the ability to initialize, develop, build, test, and deploy the entire process. There is a complete Monorepo infrastructure that can be used directly to develop business projects. 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.

conclusion

To sum up, Monorepo’s development model is to transform independent projects into a unified engineering whole, to solve the various pain points under MultiRepo, and to improve the efficiency and quality of the project. Finally, I have a question. After Monorepo has solved the previous pain points, what new problems have emerged? Can these problems be solved? Welcome to join us in the comments section.

Why is modern front-end engineering increasingly inseparable from Monorepo?

Bytedance IES front-end architecture team is in urgent need of talents (P5 / P6 / P7 has a lot of HC), welcome to add my wechat sanyuan0704 to do something about it.