“What will be hot and what to learn in 2022? This article is participating in the” Talk about 2022 Technology Trends “essay campaign.

The introduction

In version control systems, monorePO (” mono “stands for” single “and” repo “is short for” repository “) is a software development strategy in which the code for many projects is stored in the same repository. — Wikipedia

Monorepo-based solutions have become popular in large front-end projects, such as Google and Facebook, as well as well-known open source projects such as Babel and VuE-Next within the community, which use Monorepo solutions to manage their code.

The so-calledTurborepoIs a quick build system for JavaScript/TypeScript monorepos.

Monorepo

Monorepo is similar to the concept of a building that allows you to manage multiple projects by keeping different projects in a single repository.

In the Monorepo project you can manage multiple logically coexisting applications at the same time, such as desktop applications and Web applications, and even Ios applications can be saved in Monorepo if you wish.

Usually when we implement large project architectures, we try to break up some large functionality into packages by loading it through entry points in the main application.

But then the problem arises. If you split these packages in the traditional way, each individual application package should have its own workflow configuration between them. In other words, we need to repeatedly create and configure the configuration environment every time we want to separate out a new package.

Also, when building an application, if there are dependencies in some packages, we have to build the dependency package versions and redistribute them before modifying the dependency package release. This is a disaster when there are multiple project dependencies that are interdependent.

To solve these problems, Google introduced the concept of Monorepo, which uses a single project code base to manage the development, build, and release of multiple project packages.

With the advent of Monorepo, we can have more separation at the business level without the redundant project dependencies that come with separation. We can share configurations and dependencies between multiple applications based on a single repository.

At the same time, we can use mature industry tools to help manage our release between multi-dependency packages.

Advantages of Monorepo:

• Separate multiple duplicate profiles: To manage multiple applications in a code repository, we can contribute just one profile and use that configuration to build all the packages.

• Easily pull all the latest code: At this point the problem of multiple remote repositories is solved thanks to Monorepo’s solution. When pulling code, we usually just need a simple pull request to pull all the latest content of all code.

• Simpler NPM publishing: We talked earlier about versioning between dependencies. With monorepo-based solutions, we can use tools such as Lerna and Yarn Workspaces to handle the build and publish between dependent packages more automatically.

• Easier dependency management: We can promote the same dependencies in multiple projects to be managed within the project’s root dependencies, which means that this greatly reduces the amount of space that project dependencies take up on the hard disk.

• Better logic reuse solution: Based on Monorepo solution, we can reuse other modules more clearly between modules while separating logic between different applications based on packages.

Traditional solution based on Monorepo

Lerna

Lerna is a tool that optimizes the workflow for managing multi-package repositories using Git and NPM.

Lerna is widely used for versioning, building workflows, and publishing packages.

You can think of Lerna’s managed projects as one large folder, with each folder containing a separate application folder.

In addition to the separate application folders, we have a large folder to manage each separate folder. Whenever we run Lerna commands to build and publish, it internally traverses all applications to build the corresponding packages and automatically update the related dependent versions.

Yarn Workspaces

In Yarn 1.0, the developers released a feature called Workspaces for managing dependency handling between multiple applications based on the Monorepo scheme.

Generally, the industry mainstream is based on Lerna for publishing and versioning, while Yarn Workspaces are used to manage dependencies between multiple applications.

Why chooseTurboRepo

As mentioned above, in the traditional Monorepo solution, building projects based on multiple applications with dependencies can be extremely time-consuming.

TurboRepo was invented to solve the problem of slow Monorepo.

As you can see, the core code inside TurboRepo is implemented based on Go, which means better performance and faster time to handle dependency builds than traditional Monorepo solutions.

Image courtesy TurboRepo Documentation.

The figure above compares how long it took TurboRepo to build the same project as Lerna.

For example, Monorepo has three dependency application packages, A, B, and C. In this case, both packets A and C depend on packets B.

Based on Lerna you can see that only one task can be executed at a time, and only a single task can be run when Lerna Run link — Parallel is run first when building.

TurboRepo supports parallel processing of multiple tasks, a perfect solution to Lerna’s “single-threaded” build defects.

These advantages are based on TurboRepo’s official documentation:

Faster incremental builds

TurboRepo’s basic principle is never to recalculate previously completed work. TurboRepo remembers what you build and skips what has already been calculated, which means less build time when developing multiple builds.

Hash file changes through content generation

When Turborepo checks for changes in file content, it generates hashes against the content for comparison, rather than using rough timestamps to determine what content needs to be built.

Cloud cache

Usually the cache files generated for build time are mostly recorded on the local hard disk. In multi-player or Docker builds this means that there is still a huge amount of time required to generate the cache for the first time to improve efficiency.

However, the TurboRepo development team provides a feature called “cloud Caching” that allows local TurboRepo to be linked to remote caches to share caches when multiple people collaborate.

Task pipeline

Turborepo supports defining relationships between tasks through pipelines in package.json, which allows Turborepo to build strings/execution sequences intelligently for analysis modules on build content, dramatically reducing build times. Rather than supporting the operation of a single task, which is only mechanized like Lerna mentioned above.

Convention based configuration

Turborepo reduces complexity by convention, and with Turborepo we care only about simple JSON configuration to complete the project configuration.

In the browserThe configuration file

Turbo supports generating build profiles with the –profile flag, which you can import into Chrome or Edge to see which tasks take the most time.

Feature

Turbo officially supports Lerna for package management, publishing, and change log generation, as well as Turbo for task running and caching.

Turborepo may not be as brilliant as Lerna for version control and distribution, but for now the Turborepo based Monorepo solution is in my opinion a very good one.

You can check out Jared Palmer’s introduction to Turborepo in this video.

At the same time, I am actively exploring TurboRepo, and gradually trying to use TurboRepo in landing projects.

Expect Turborepo to shine in 2022 with more great solutions for Monorepo.

At the end

I believe Turborepo will be an important addition to Monorepo’s toolchain in the near future, as it solves the “slow” problems of traditional Monorepo, from build caching to pipeline-based intelligent task scheduling.

The go-based implementation inside Turborepo is also, in my opinion, a sign of the diversity of JavaScript tools on the horizon.

For better performance, most people will no longer be limited to developing JavaScript tools in JavaScript, preferring to use other high-threshold languages.