background

Demander: there is a module that needs to be applied to another project, and when this common module is updated, it canAutomatically updateTo the corresponding project.

When I first got this requirement, the first thought in my mind was to extract a public component, type an NPM package, it should be ok, as for the update, this… How do you do automatic updates? So I started research, reading materials, etc., to see if there was a plan that met the requirements.

Four options. How do you choose?

In the process of checking materials, we found four solutions: MonoRepository, manual Copy Paste, NPM Dependency, Git Submodule, and Bit. Let’s analyze them respectively.

Manually Copy Paste

Well, I think this project can be done by a technician who has worked for one or two years, but as a veteran who has struggled for six years in the workplace, it is also too inconsistent with my “craftsman spirit”. This solution will definitely not work, so here’s how to do it: make a copy of the public module into the corresponding project, and make changes to both sides as required.

Bit

Open infrastructure for component-driven applications to speed and scale development.

Bit can help the team track the status, version and other information of components, realize the synchronization of codes, and achieve the effect of rapid iteration and rapid release. I think it is a very good tool if it is an open source project. By creating accounts, Bit platform helps us to track the status of components in real time, which is why we do not use Bit. Components may contain modules that are highly relevant to business, which may involve sensitive information, so it is not suitable to use accounts of third-party platforms to track our components. Deprecated due to safety issues.

Monorepo

A monorepo (“mono” meaning ‘single’ and “repo” being short for ‘repository’) is a software development strategy where code for many projects is stored in the same repository.

Traditionally, we have used Multiple Repository. Each project has its own code repository, and each team has access to the corresponding code base, which makes it convenient to manage account permissions and other functions. Moreover, the CI/CD of each project is also independent and easy to set up. MonoRepo required us to manage different projects in a separate repository, and CI/CD required additional script implementation. So what kind of scenario does MonoRepo fit in?

  • When the team has many code repositories, such as dozens or even more than a hundred, using a Multiple Repository is obviously too painful to manage.
  • When a project has many dependencies, tracking versions of those dependencies can be tricky. For example, multiple projects have the same dependency. When the dependency version changes, the number of projects we have needs to do repeated dependency update operations.

This is where MonoRepo comes in, and Lerna is a great tool for MonoRepo. Lerna helps us manage the relationship between projects, share running scripts, simplify the relationship between dependencies, and provide very useful commands.

Here is an example of the directory structure of the Lerna codebase:

Many businesses and organizations use MonoRepo, including but not limited to: Google, Facebook, Babel, React, Angular, Ember, Vue, and more.

For us, to create MonoRepo, we need to merge existing code projects into MonoRepo. Plus, as mentioned above, we need additional scripts to build and publish different projects. When I run Lerna Publish, I create tags for all projects at the same time. If a project hasn’t changed, it will, which makes it a bad time to do release management.

Above, MonoRepo was also passed.

Meta Repo

Meta Repo is based on Multiple Repository, which solves the problem of managing Multiple repositories. For example, you can clone Multiple repositories with a single command. A single command installs all repository dependencies so that every project does not have to do the same thing repeatedly; Git commits can also be applied to all projects. Still can guarantee the authority management of different projects. Meta is really more of a tool, a plugin, that helps us do a lot of things automatically.

As for the topic of this article, sharing common modules is not very relevant, so this scheme is not considered.

Git Submodule

The Git Submodule I used in previous projects was a separate repository for storing ICONS, so that our different projects could pull ICONS from a repository without having to add them to each project.

Similarly, the repository of common modules is a separate repository, packaged with any version updates into browser-ready JS, and projects that need to use the module are introduced as git submodules. Another important question, then, is how to update the project automatically when the public module version is updated. We used Gitlab’s CI/CD feature.

You can set up GitLab CI/CD across multiple projects, so that a pipeline in one project can trigger a pipeline in another project.

We used GitLab’s own multiple Pipelines. When public modules change, CI/CD process will be triggered for the projects using it. Sample code:

staging:
  variables:
    ENVIRONMENT: staging
  stage: deploy
  trigger: my/deployment
Copy the code

Looks like we found the solution we were looking for.

NPM dependency

NPM Dependency is essentially the same as the Gitlab Submodule above. The difference is, first we need to pack public modules into NPM packages and put them into our own Registry, then the corresponding project uses @latest to obtain the latest version of public modules, so the trigger method is also using Gitlab multiple pipelines.

This seems to be the right solution.

To sum up, there were four kinds originally, but I found another one in the process of writing. If I continue to study, there may be more solutions. The simplest and most suitable way is Git Submodule. As a front end, especially a small front end of 6 years, I may still use NPM Dependency, because it is more in line with version management mode. It may evolve, however, with Git Submodule implementation and NPM Dependency replacement. Stubborn face: 😛

References:

  • github.com/teambit/bit;
  • En.wikipedia.org/wiki/Monore… ;
  • Patrickleet.medium.com/mono-repo-o…
  • Github.com/mateodelnor…