Lerna management packages based on best practices of project Monorepo

This article first appeared in vivo Internet technology
Author: bright vertical hole

For the maintenance package had more students who will encounter a multiple-choice questions, the package is placed in a warehouse or on the maintenance of multiple warehouse maintained separately, this paper describes an example of how to manage multiple package based on Lerna and integration with other tools, to create efficient and perfect workflow, eventually forming a best practice

background

Recent exposure at work to a project, which is to maintain a set of CLI, sent to npm altar developers. Look at a map:

On the root directory of the project repository on the file folder of three sub-modules, corresponding to three package, after the familiar build and release processes, a bit silly. As shown in the workflow:

1. Use webpack, babel and uglifyjs pkg-a of the src compiled into dist

2. Use webpack, babel and uglifyjs pkg-b of the src compiled into dist

3. Use webpack, babel and uglifyjs the pkg-main to compile the src dist

4. Finally manner using the copied file, the assembly pkg-main, pkg-a, pkg-b in the compiled file to pkg-npm, the final release for up to npm.

Pain points

1. Good debugging. Because the final package is assembled by the way files are copied together, and are compressed, not from top to bottom to form a commissioning process (the actual work can only add log, and then re-assembled again to compile the package to see results )

2. Dependency package is not clear. pkg-a, pkg-b simply no version management, like is the source level, but the logic and relatively independent. pkg-main of package.json eventually be copied to the pkg-npm but depends pkg-a, pkg-b in some packages, it should pkg-a, pkg-b is dependent incorporated pkg- in the main. package.json coupling pkg-main and pkg-npm together, would have led to some development projects will be published to rely npm go into pkg-npm dependencies.

3. Dependent packages redundancy. Can be seen, pkg-a, pkg-b , pkg-main To compile respectively, are dependent on the babel, webpack the like, respectively, to the respective directory cd installation dependent.

4. Posted need to manually modify the version number.  Because in the end only released a package, but the actual logic of this package that is required to install a global but also local installation, business is not open, resulting to be installed twice. Coupled together, even with npm link can lead to difficult to debug,

5. Hair version does not CHANGELOG.md.  Because pkg-a, pkg-b are not really manage versions, so there is no perfect CHANGELOG to record the changes since the last release has come.

The entire project is not managed like a up Monorepo. What is Monorepo it?

Monorepo vs Multirepo

Monorepo stands monolithic repository, i.e. unitary warehouse, the corresponding Multirepo (multiple repository), where the "single" and "multi" relates to the number of modules in each warehouse managed.

Multirepo is a more traditional approach, that is, each package individually using a warehouse to manage. For example: Rollup, ...

Monorep is to put all the relevant package are placed in a warehouse management, each package independent publication . For example: React, Angular, Babel, Jest , Umijs, Vue ...

A picture is worth a thousand words:

Of course, in the end what kind of better management, the eyes of the beholder, the wise see wisdom. The former allows diversification (each project can have its own build tool, dependency management strategy, the unit test method), which hopes to centrally manage and reduce communication cost difference between the project brings.

Although the split sub-storage, is split sub-item package npm isolated natural solutions, but the warehouse contents association occurs, there is no one with the debug mode is more efficient than on the source.

Combined with our project and business needs of the actual scene, natural MonoRepo! Because the ultimate goal of the project is to enable business development 100% focus on the business logic, so it's not just scaffolding framework needs to solve the problem from the automation, design this involves the management of the warehouse design.

An ideal development environment can be abstracted like this:

"Only care about business code can be directly reuse across business without concern for multiplexed mode, all the debugging code in the source code."

In the front-end development environment, multi-Git Repo, multi npm is this ideal of resistance, which leads to reuse should be concerned about the version number, the debugger needs npm link. These are MonoRepo biggest advantage.

Using the tools mentioned in the above figure is today's hero Lerna! Lerna is the industry's best-known Monorepo management tools, full-featured.