Preera: Lerna was known through Babel around the beginning of 16, and the concept of Monorepo was first heard. It turned out that lerNA was so unstable that it wasn’t used at the time. After nearly a year, I feel that I have done well in all aspects in the recent trial, so I have started to use it in the project. Probably Google under the domestic seems to have no article to introduce this piece of content, so the power of this article all come from this.

What is monorepo?

Monorepo is a unified source code repository used by an organisation to host as much of its code as possible.

Monorepo isa way to manage your organisation code by putting modules in a single repO instead of a single module.

Babel, React, Angular, Ember, Meteor, Jest and many others use Monorepo to manage source code.

What is Lerna?

Lerna is based on the concept of Monorepo in the tool side implementation.

The historical context of lerna’s emergence

The historical background of Lerna is the superiority and inferiority of Monorepos and Multirepos in project management.

Here’s what I feel personally:

Multirepos

Disadvantages:

  • In Multirepos we usually have one repO per project or one module per repO, and in fact because of the project or module we have to split it up into different organisations for function or attribute or history reasons, This leads to a situation where you don’t know where to find a REPO when it comes to personnel handover or managing your own project. (This can be particularly painful for development involving historical baggage)

  • “Issue” does not know where to mention, resulting in confusion in project management. (Atool -build and DORA both have this dilemma.)

  • Versioning overhead. First of all, semver does bring a lot of convenience to versioning, but it tends to be patch, which can be a disaster when core Module releases minor or Major versions. For example, when the Core of DORA (plug-in Server) needed to change, we had to synchronize all the official plug-ins, which involved over 20 warehouses and was completely manual labor. At the same time, in daily development, we may have multiple REPOs in one iteration, on the one hand, we need to hack into the local repository by NPM link, on the other hand, we need to manually switch to the corresponding repository each time for operations such as Lint test. To do this we have to open multiple tabs in Terminal, which is definitely an eye and a physical task

  • Changelog carding is another disaster, and in the case of Multirepos managing the project, we need to manually synchronize all the changed repositories and finally list a Changelog. It would make sense if all of them were developed by one person, but in fact, normal iterations are usually multi-person development and collaborative development mode. In this case, it is difficult to count whether the module that the warehouse depends on has been updated or what kind of work has been done.

And so on.

Using Monorepo above problems can be solved.

However, using the Monorepo scheme has its drawbacks

  • A single REPO is large in size
  • ??

The above are just some of my personal feelings about the project. Let’s also look at Why Babel chose Monorepo

How to manage projects with LERNA

step 1:

$ npm install --global lernaCopy the code

step 2:

$ git init monorepo-example
$ cd monorepo-exampleCopy the code

step 3:

$ lerna initCopy the code

After the tree is executed in terminal, we can see that the directory structure is

$monorepo-example git:(master) qualify tree. ├── download.jsonCopy the code

step 4:

$monorepo-example git:(master) qualify mkdir packages && CD packagesCopy the code

Create the Packages directory that will hold all officially maintained modules from now on

step 5:

$packages git:(master) qualify mkdir monorepo-exemplary-module-a && CD monorepo-exemplary-module-a && NPM init $packages Git :(master) qualify mkdir monorepo-example-module-core && CD monorepo-example-module-core && NPM initCopy the code

Create two new packages and initialize package.json with NPM init

At this point our Packages directory structure is

➜ packages git:(master) go onto those who qualify. ├── ├─ ├─ go onto those who qualify. Go onto those who qualify package.jsonCopy the code

Suppose module-a depends on module-core refer to the monorepo-example case in detail

step 6:

$monorepo-example git:(master) qualify lerna bootstrap lerna v2.0.0-beta.31 Bootstrapping 2 packages Preinstalling packages Installing external dependencies Symlinking packages and binaries Postinstalling packages Prepublishing packages Successfully bootstrapped 2 packages.Copy the code

Executing lerna bootstrap will automatically perform NPM install and NPM link operations for Module -A. As shown in figure

Isn’t it very convenient?

step 7:

$monorepo-example git:(master) publish lerna v2.0.0-beta. Checking for updated packages... ? Select a new version (currently 0.0.0) Patch (0.0.1) Changes: -monorepo-example-module -a: 0.0.1 => 0.0.1 -monorepo-example-module-core: 1.0.0 => 0.0.1? Are you sure you want to publish the above changes? Yes Publishing packages to npm... NPM WARN dist-tag add latest is already set to version 0.0.1 monorepo-example-module-a NPM WARN dist-tag add latest is Already set to version 0.0.1 Pushing tags to git... To [email protected]:pigcan/monorepo-example.git 0f8674c.. 2 ecb064 master - > master To [email protected]: pigcan/monorepo - example. Git * [new tag] v0.0.1 - > v0.0.1 Successfully Published: - [email protected] - [email protected]Copy the code

Execute Lerna publish and answer a few questions to push your package to NPM.

Of course, the actual situation in use, will be more complicated, more content will be left to you to see the official instructions, the basic are simple and clear content, if there is no clear place welcome to ask questionsOfficial documentation Commands

Use Lerna-Changelog to generate Changelog

In real development, we often encounter a difficult problem is the sorting of Changelog. Lerna provides a very useful Lerna-Changelog library, which will make it very convenient to solve this problem under certain standard development. Let me give you an idea of how to use this warehouse over here.

step 1:

$ monorepo-example git:(master) npm install lerna-changelog --save-devCopy the code

Install the lerna-Changelog dependency

step 2:

Modify lerna.josn You need to add lerna-Changelog configurations

+"changelog": {
+  "repo": "pigcan/monorepo-example",
+  "labels": {
+    "tag: bugfix": "Bug fix",
+    "tag: enhancement": "Enhancement"
+  },
+  "cacheDir": ".changelog"
+}Copy the code

The key of labels must be defined in the Github repository

You can use the following link github.com/pigcan/mono… To create labels, I added tag: Bugfix and Tag: Enhancement on Github

step 3:

$ export GITHUB_AUTH="..."Copy the code

The GITHUB_AUTH token field can be obtained by applying for a token on Github.

This is the end of the step, but in order to achieve the desired results must follow certain rules of development, in fact, need to have good development habits, here I recommend personal habits.

As is shown in the case github.com/pigcan/mono… Record your project’s bugs, enhancements, etc., in the issue and label them accordingly.

Create a branch to resolve the content credited to the corresponding issue.

$  monorepo-example git:(bugfix-core) git branch
* bugfix-core
  enhance-module-a
  masterCopy the code

For example, if we fix core problems here, the final commit log is recommended as

$ git commit -a -m "core-bugfix: the xxx problem had fixed, Close #1"
Copy the code

In the COMMIT message, associate the problem solved with the corresponding issue so that it is clear at a time when you need to roll back that part of the code later.

Once the Bugfix-core branch is committed, we can create a PR on Github with that branch,

When creating pr, be sure to select the corresponding label **. In this case, I need to select Tag: Bugfix

For details, see Pigcan /monorepo-example#3

It runs locally once the branch’s code is merged into the trunk

$  monorepo-example git:(master) node_modules/.bin/lerna-changelog

## Unreleased (2017-01-05)

#### Bug fix
* `monorepo-example-module-core`
  * [#3](https://github.com/pigcan/monorepo-example/pull/3) core-bugfix: the xxx problem had fixed, Closes [#1](https://github.com/pigcan/monorepo-example/issues/1). ([@pigcan](https://github.com/pigcan))

#### Committers: 1
- pigcan ([pigcan](https://github.com/pigcan))Copy the code

See if you’ve generated a nice Changelog log.

Run lerna-Changelog once to get the log before publish (commit information will be cleared after publish)

Once publish we can create release note github.com/pigcan/mono…

Here is the final result, isn’t it cool and convenient?

Refs

  • lerna
  • lerna-changelog
  • The Case for Monorepos
  • Advantages of monolithic version control
  • New wave modularity with Lerna, monorepos, and npm organizations
  • Monorepo, scaling projects