使用Lerna以Monorepo的方式开发项目

起因

源于一次面试：我让面试者展开讲了一下她的项目经历（一个内部使用的组件库）。多个包的维护方式让她在开发过程中浪费了大量的时间。虽然是用的Multirepo的组织方式，但是她并知道Multirepo的管理理念，且更不懂Monorepo。这我岂能容忍，必须解释一番。

Monorepo 和 Multirepo 是两种不同的源码管理理念。

Monorepo 是把所有的相关项目都放在一个仓库中（例如：React, Angular, Babel, Jest, Umijs, ...）

Multirepo 则是按模块把子项目拆分到多个仓库中。

Multirepo允许多元化发展（各项目可以有自己的构建工具、依赖管理策略、单元测试方法）；Monorepo希望集中管理，减少项目间的差异带来的沟通成本。

现在，越来越多的公司采用Monorepo的方式来管理包代码。

原因：

Multirepo 缺点：

• 仓库比较多，在权限卡控比较严格的情况下，找起来非常吃力（大厂常态）
• 版本管理比较麻烦
• 修复一个包的bug，需要找到所有的依赖包都修改一遍，开销很大
• 每一个包都需要配置一份基建，冗余。

Monorepo 优点：

• 仓库收拢，就一个。
• 方便版本管理和依赖管理
• ChangeLog比较方便处理
• 可以共用一套基建

直接使用Monorepo的时候又比较麻烦，Lerna 帮我们解决了这个问题。

本着 BB is nothing，show me the code 的原则，傻瓜式的带你上手lerna整个流程。

开始

为了方便，我们就基于github。

1. 在自己的github上新建一个仓库
   
2. clone到本地，在项目中checkout 一个新的分支，test（master不允许发布）
3. 全局安装lerna npm i lerna -g，如果有就跳过。
4. 项目内执行 lerna init 用来初始化一个lerna工程。
   
5. 增加两个包

   lerna create ddemo01
   lerna create ddemo02
   

   

6. 给package安装依赖包。

   lerna add lodash  // 为所有的package安装
   lerna add moment --scope=ddemo01  // 为ddemo01 安装包
   lerna add ddemo01 --scope=ddemo02   // ddemo02包依赖ddemo01，内部模块依赖，monorepo 常用手段。
   

   

7. 可以进行一些开发工作了, 你可以在 ddemo01 中新建一个index.js ,然后随便写点代码，巴拉巴拉~
8. 发布
   发布前需要做的几个重要工作。 确保你都执行了。
   1. 发布前需要将仓库commit，且将分支 push上去。
   2. 登录npm账号 npm login （因为我们要发布到npm上），如果你是内部源，就走内部源的认证方式。
   3. 执行 lerna publish ，选择一个版本，一路回车就行。
      
      
      

9. 发布成功，我们可以到npm 上去查看下。

   

到这里就发布完了，可以正常使用了，如果你想做一下优化，那么你可以按照下面接着去做。

11. 现在项目中每个packages下都有一个node_modules，这是因为我们在执行 lerna add的时候都会在 安装在 package 目录下的 node_modules 目录下，会导致安装多次，且维护比较麻烦。我们可以使用 --hoist 来把依赖提升到全局根目录，来降低管理成本。

lerna bootstrap --hoist

为了之后不用每次安装的时候都增加 --hoist ，我们可以在lerna.json中配置一下。

{
  "packages": [
    "packages/*"
  ],
  "command": {
    "bootstrap": {
      "hoist": true
    }
  },
  "version": "0.0.1-alpha.0"
}

12. 因为之前我们已经在每个packages下安装过了，我们可以执行 lerna clean 清理一下。清理之后长这样。
    
13. 这里你可以对每个pkg进行一下开发工作，这里我们就简单的写几个console。
14. 执行一下 lerna updated 可以查看一下哪些包被修改了
15. 可以执行 lerna publish 再次发布一下。选择要发布的版本号就ok了。

这里我们需要了解一下 lerna publish 都做了哪些事情

• 运行lerna updated来决定哪一个包需要被publish
• 如果有必要，将会更新lerna.json中的version
• 将所有更新过的的包中的package.json的version字段更新
• 将所有更新过的包中的依赖更新
• 为新版本创建一个git commit或tag，并推送到远程仓库中。
• 将包publish到npm上

16. 我们可以修改单个的包，publish的时候就会单独发布当前包。其他包如果引用当前包也会增加对应的版本。相比于人工维护版本号，这种方式更加稳妥。
17. 现在你可以修改存在的包或者是增加新的包，可自由玩耍，不需要担心版本和内部依赖的问题。lerna都会帮你处理好。

至此，一个 MVP 的版本都完成了。

名词解释： MVP是指最小可行性产品：minimum viable product；也是我团一直奉行的方法论

Lerna的整个流程大致就是这样的了，你可能好奇，怎么没有打包，压缩，调试等等步骤。因为这些不是Lerna的范畴。

lerna不负责构建，测试等任务，它提出了一种集中管理package的目录模式，提供了一套自动化管理程序，让开发者不必再深耕到具体的组件里维护内容，在项目根目录就可以全局掌控，基于npm scripts，可以很好地完成组件构建，代码格式化等操作，并在最后一公里，用lerna变更package版本，将其上传至远端。

结束

• 祝大家玩得开心
• 求简历，微信联系 【yumocode】