This article was originally published on the public account CoyPan as expected
Writing in the front
On September 21, 2019, I participated in the 5th FEDAY. At the meeting, I came into contact with the concept of Monorepo for the first time after listening to teacher Wang Ze’s sharing. This article is combined with teacher Wang Ze’s share, their own practice after a certain summary.
The pictures in this paper are all from the PPT screenshots I shared with the team
Monorepo
One way to manage projects: manage multiple projects under one Git repository, suitable for large teams, framework development, library development, etc.
Status quo of Online projects
When I saw this concept, I immediately thought of a REPO on my team that had a directory that looked something like this:
- Unified technology stack
- Reduce backup costs between team members
- Promote efficiency
- Everyone can change any part of the code, change the effect of real-time display, easy debugging
- There is flexibility in business development to extract code as a common module
- Saves the time needed to grant REPO permissions to new team members in the case of multiple REPOs
The approximate repO organization looks like this:
The repO organization shown above is perfectly adequate for the team’s current business development, since each page is relatively simple. But is there a problem with developing a large complex project?
What about large complex projects
The situation above is very common in normal development. Project B may not have the time and manpower to do regression testing, but project A is in A hurry to launch, so it does not care so much. This is generally not a problem if the business complexity is small. What about large, complex projects? Does project A copy base library A again for modification?
The solution: version management. Components are versioned and hosted in a component repository within the company.
What exactly is monorepo
Microsoft defines it as follows:
Take a look at the famous Babel and React:
Here’s my own summary:
rush.js
Microsoft, a project management tool created specifically for Monorepo. Rushjs. IO.
Rush. js solves two important problems: Phantom Dependencies and Doppelgangers. Let’s look at these two problems first.
phantom dependencies
Dependencies that are not specified in package.json but can be referenced in the project.
After PM3.0, yes. This is because: the original tree structure of NPM causes dependency redundancy and too deep path. Npm3 flattens out, turning the dependency of different classes into peer dependencies. So we can reference it directly in the project.
Phantom Dependencies problem:
- Dependency version chaos
- Depend on the lost
General solution: code specification; Use code review tools to prevent this from happening. But…
doppelgangers
The same dependency is installed multiple times, resulting in bloated projects and slow packaging.
Rush. js Symlink mechanism
Rush would install all project dependencies under Common/Temp in the REPo root and then provide Symlink to reference in each project. In the original project, the node_modules structure will remain the same.
Look at an example:
Rush guarantees that only the dependent Symlink declared in package.json will remain in the project’s node_modules. This naturally resolves phantom dependencies
Rush installs all the dependencies in one place, installs all versions of the same dependency at the same time, and makes symlink available to the project, which naturally solves doppelgangers.
In addition, Rush makes an intelligent determination of the dependent version (SemVer) to prevent repeated installation of dependencies. For example, two projects rely on a third-party library at the same time. The first project relies on ^1.2.0 and the other relies on version 1.5.0. Only 1.5.0 will be installed when rush installs dependencies.
A simple introduction to the use of rush.js
Here is a brief introduction to the use of rush.js.
-
rush.json
-
rush build
-
rush update
-
rush change
-
rush publish
Write in the back
This article introduces Monorepo and briefly explores rush.js. Monorepo already has many cases, such as Babel and React mentioned above. Monorepo management also has very mature tools, such as the famous Lerna. After doing a little research, my impression of rush.js is that it’s pretty standard, but really expensive for the team to get started.
Currently, the business I am in charge of does not have a suitable scenario for Monorepo, so I have not had a deeper understanding and comparison of rush.js, Lerna and other tools. Hope experienced big guy can share his experience deeply.
References:
rushjs.io/
www.zhihu.com/question/33…
