The cause of

From an interview: I asked the interviewee to expand on her project experience (a library of components used internally). The maintenance of multiple packages cost her a lot of time during development. She was organized in the same way as Multirepo, but she didn’t know the management philosophy of Multirepo, much less Monorepo. I must explain how I can bear it.

Monorepo and Multirepo are two different source management concepts.

Monorepo puts all related projects in one repository (e.g. React, Angular, Babel, Jest, Umijs…).

Multirepo splits subprojects into warehouses by modules.

Multirepo allows diversification (each project can have its own build tools, dependency management strategies, unit testing methods); Monorepo wanted to centralize management and reduce communication costs associated with differences between projects.

More and more companies are now adopting the Monorepo approach to managing package code.

The reason:

Multirepo faults:

  • There are many warehouses, and it is very difficult to find them under the condition of strict permission card control (normal for large factories)
  • Versioning is cumbersome
  • Fix the bug of a package, need to find all the dependent packages to modify again, the overhead is very large
  • Each package needs to be configured with a piece of infrastructure, redundancy.

Monorepo advantages:

  • The warehouse is closed, just one.
  • Easy version and dependency management
  • ChangeLog is easy to handle
  • We can share one infrastructure

Using Monorepo directly was a bit of a hassle, Lerna helped us solve this problem.

In line with the principle of BB is nothing, show me the code, fool take you to start the whole process of LERna.

start

For convenience, we’ll base it on Github.

  1. Create a new repository on your Github
  2. Clone to local, checkout a new branch in the project, test (master is not allowed to publish)
  3. Install LERNA globallynpm i lerna -gIf yes, skip it.
  4. In-project executionlerna initTo initialize a LERNA project.

6. Add two packs

lerna create ddemo01
lerna create ddemo02
Copy the code

7. Install dependency packages for package.

Lerna add moment --scope=ddemo01 --scope=ddemo02 Ddemo02 package depends on Ddemo01, internal module depends on monorepo common means.Copy the code

8. It’s ready for some development work. You can do it atddemo01Create an index.js file and write some random code, blah, blah, blah ~ 9.releaseA few things you need to do before launchingImportant work. Make sure you follow through.

  1. The repository needs to be committed and the branch pushed up before publishing.
  2. Log in to the NPM accountnpm loginIf you are an internal source, use internal source authentication.
  3. performlerna publish, select a version and press Enter.

10. Successful release, we can go to NPM to check.

! [](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/7cafb73a1e79412da7755a3550cac984~tplv-k3u1fbpfcp-zoom-1.image)Copy the code

That’s it, and it’s ready to use. If you want to optimize, you can follow the steps below.

  1. There is now a node_modules under each packages in the project because we are executinglerna addNode_modules will be installed in the package directory, which will lead to multiple installation, and maintenance is troublesome. We can use the –hoist to promote dependencies to the global root to reduce administration costs.
lerna bootstrap --hoist

Copy the code

So instead of adding –hoist every time we install it, we can configure it in lerna.json.

{" packages ": [" packages / *"], "command" : {" bootstrap ": {" hoist" : true}}, "version" : "0.0.1 - alpha. 0"}Copy the code
  1. Since we have previously installed it under each of the packages, we can implement itlerna cleanLet’s clean it up. This is what it looks like after it’s cleaned.

13. Here you can do some development work for each PKG, so let’s just write a few consoles. 14. Do itlerna updatedCheck which packages have been modified. 15lerna publishOnce again. Just select the version number you want to release.

Here we need to know what Lerna Publish does

  • Run lerna updated to determine which packages need to be published
  • If necessary, version in lerna.json will be updated
  • Update the version field of package.json in all updated packages
  • Update all dependencies in the updated package
  • Create a Git commit or tag for the new release and push it to a remote repository.
  • Publish the package to NPM
  1. We can modify individual packages and publish the current package separately. Other packages that reference the current package will also add the corresponding version. This is more secure than manually maintaining version numbers.
  2. Now you can modify existing packages or add new ones, and play with them without worrying about versioning or internal dependencies. Lerna will take care of it for you.

At this point, a version of the MVP is complete.

MVP refers to a minimum viable product; It is also the methodology that our regiment has always pursued

The whole process of Lerna looks like this, and you may wonder why there is no packaging, compression, debugging, etc. Because these are not Lerna’s categories.

Lerna is not responsible for construction, testing and other tasks. It proposes a directory mode for centralized management of package and provides a set of automatic management program, which enables developers to have global control in the root directory of the project without having to dig deeply into specific components to maintain content. Component construction can be completed well based on NPM scripts. Code formatting and other operations, and in the last kilometer, change the package version with Lerna and upload it to the remote end.

The end of the

  • Have a good time
  • Please resume