Monorepo簡介與建設實踐

做者：重明前端

Monorepo和Multirepo對比

須要注意一點：monorepo和multirepo不是框架，不是庫。是一種管理項目的概念node

monorepo

將全部的模塊統一的放在一個主幹分支之中管理。不進行分庫存儲，當有特定的須要的時候進行分支，可是問題修改仍是在主幹上操做，並有專門人員合併到分支內容上，在特定需求完結的時候，分支也將會被廢棄。git

優勢：npm

1.統一的規範，語言，和IDE帶來的是結構的完整穩定。json

2.按照統一的標準進行開發，使程序穩定性更良好，更易解讀。安全

3.標準化的開發流程，規避不少沒必要要的衝突與錯誤。markdown

缺點：app

1.項目過大，難以管理。框架

2.因爲統一的標準，不一樣的團隊可能須要對於新的規範和IDE進行了解學習，須要時間。微服務

3.修改和開發可能變得繁瑣，減慢效率。

multirepo

將項目分化成爲多個模塊，並針對每個模塊單獨的開闢一個repo來進行管理。

優勢：

1.團隊本身的IDE，語言，以及工做步調。

2.模塊更小，更易維護。

3.開發效率更高。

缺點：

1.合併困難，每一個模塊規範不一樣，同步和編譯時這些問題將會集體爆發。

2.難以保證穩定性。

3.因爲可能存在不一樣語言開發，或者不一樣IDE的狀況，新建或者更新構建變得困難

你們看到multirepo是否是有點眼熟？對了，這個就是微服務的概念。你們多多少少對微服務都有所瞭解，這裏就不展開了，日後能夠單獨分享

Lerna

Lerna是npm模塊的管理工具，爲項目提供了集中管理package的目錄模式，如統一的 repo 依賴安裝、package scripts和發版等特性。

想要初識monorepo上邊這句話可能已經一腦殼問號了？不要慌，咱們翻譯一下：

問：實現monorepo一共分幾步？

答：一共分三步 ---

--- 安裝Lerna
--- 使用Lerna （根據Lerna提供的結構放置項目）
--- 提交項目

是否是明白了(╹▽╹)？好！那接下來我們看一下Lerna是怎麼使用的

安裝Lerna

npm i -g lerna
複製代碼

好的，恭喜你完成了第一步！

使用Lerna

經常使用lerna命令

lerna init 建立一個新的lerna庫或者是更新lerna版本

lerna add 添加一個包的版本爲各個包的依賴

lerna create 新建包

lerna list 列舉當前lerna 庫包含的包

lerna changed 顯示自上次relase tag以來有修改的包，選項通 list

lerna diff 顯示自上次relase tag以來有修改的包的差別，執行 git diff

lerna clean 刪除各個包下的node_modules

初始化項目

lerna init
複製代碼

初始化後，會生成 packages 空目錄和 package.json 和 lerna.json 配置文件，配置文件以下:

//package.json
{
  "name": "root",
  "private": true, // 私有的，不會被髮布，是管理整個項目，與要發佈的npm包解耦
  "workspaces": ["packages/*"], // workspace配置
  "devDependencies": {
    "lerna": "^3.22.1"
  }
}

//lerna.json
{
  "packages": [
    "packages/*"
  ],
  "version": "0.0.0",
  "npmClient": "yarn", // workspace配置
  "useWorkspaces": true // workspace配置
}
複製代碼

這裏有yarn workspace的命令混入其中，代碼中已有標記。它主要是爲安裝依賴的配置調整。 Lerna的一些操做較平常的操做而言有些蹩手，因此咱們使用workspace來作能更加容易接受

建立npm包

執行命令後可修改包信息，這裏建立@monorepo/feihe-project @monorepo/feihe-components 和 @monorepo/feihe-utils

lerna create @monorepo/feihe-project -y
lerna create @monorepo/feihe-components -y
lerna create @monorepo/feihe-utils -y
複製代碼

安裝依賴

lerna add lodash // 爲全部 package 增長 lodash 模塊 

// 爲 @monorepo/feihe-utils 增長 lodash 模塊(lodash可替換爲內部模塊，如@monorepo/feihe-components)
lerna add lodash --scope @monorepo/feihe-utils 
複製代碼

固然也能夠在各個package.json中的dependencies或devDependencies添加依賴，也可使用yarn或npm在各包中進行安裝，沒有強行限制。好比從根目錄到packages下全部包執行安裝依賴，執行yarn install便可

除此以外，咱們能夠將項目內的工具庫@monorepo/feihe-utils導入至項目@monorepo/feihe-project中

lerna add @monorepo/feihe-utils --scope=@monorepo/feihe-project
複製代碼

在工具庫中可直接導出es包，安裝依賴後直接使用

執行命令

當咱們須要在根目錄執行packages下的scripts命令時能夠這樣:

yarn workspace @monorepo/feihe-project run dev
複製代碼

固然也能夠進入但願執行的目錄下執行yarn run dev，都沒有問題

清理環境

在依賴亂掉或者工程混亂的狀況下，清理依賴

lerna clean # 清理全部packages的node_modules目錄，不能刪除根目錄的node_modules
yarn workspaces run clean # 執行全部package的clean操做（應是需自行寫腳本）
複製代碼

注意：以上兩種清理的是packages的node_modules，不包含根目錄，根目錄須要自行刪除。yarn workspaces run clean你們可能也看出來了，須要每一個package中都在scripts中配置clean命令，因此是否是很坑...

提供一個解決方案：

在根目錄的package.json中設置一下

// package.json
{
  "scripts": {
    "clean": "rimraf node_modules & lerna clean -y" // 清理全部依賴
  }
}
複製代碼

執行此命令須要安裝rimraf包

npm install -g rimraf
複製代碼

提交項目

在構建和發佈以前還須要作一些關於代碼提交的配置

commitizen && cz-lerna-changelog

commitizen 是用來格式化 git commit message 的工具，它提供了一種問詢式的方式去獲取所需的提交信息。

cz-lerna-changelog 是專門爲 Lerna 項目量身定製的提交規範，在問詢的過程，會有相似影響哪些 package 的選擇。

咱們使用 commitizen 和 cz-lerna-changelog 來規範提交，爲後面自動生成日誌做好準備。由於這是整個工程的開發依賴，因此在根目錄安裝：

yarn add commitizen cz-lerna-changelog -D -W
複製代碼

安裝完成後，在 package.json 中增長 config 字段，把 cz-lerna-changelog 配置給 commitizen。同時由於commitizen不是全局安全的，因此須要添加 scripts 腳原本執行 git-cz

{
  "scripts": {
    "commit": "git-cz"
  },
  "config": {
    "commitizen": {
      "path": "./node_modules/cz-lerna-changelog"
    }
  }
}
複製代碼

以後在常規的開發中就可使用 yarn run commit 來根據提示一步一步輸入，來完成代碼的提交。

commitlint && husky

上面咱們使用了 commitizen 來規範提交，但很難靠開發自覺使用 yarn run commit 。萬一忘記了，或者直接使用 git commit 提交怎麼辦？因此在提交時校驗提交信息，若是不符合要求就不讓提交，並提示。校驗的工做由 commitlint 來完成，校驗的時機則由 husky 來指定。husky 繼承了 Git 下全部的鉤子，在觸發鉤子的時候，husky 能夠阻止不合法的 commit，push 等等。

安裝 commitlint 以及要遵照的規範：

yarn add -D -W husky @commitlint/cli @commitlint/config-conventional
複製代碼

在工程根目錄爲 commitlint 增長配置文件 commitlint.config.js 爲commitlint 指定相應的規範

module.exports = { 
    extends: ['@commitlint/config-conventional'] 
}
複製代碼

在 package.json 中增長以下配置

"husky": { 
    "hooks": { 
        "commit-msg": "commitlint -E HUSKY_GIT_PARAMS" 
    }
}
複製代碼

"commit-msg"是git提交時校驗提交信息的鉤子，當觸發時便會使用 commitlint 來校驗。安裝配置完成後，想經過 git commit 或者其它第三方工具提交時，只要提交信息不符合規範就沒法提交。從而約束開發者使用 yarn run commit 來提交。

流程簡介

git add .

yarn run commit

git push origin xxxx(分支)

打包發佈

咱們能夠本身構建拓撲排序規則，很不幸的是yarn的workspace暫時並未支持按照拓撲排序規則執行命令,雖然該 rfc已經被accepted，可是還沒有實現, 幸運的是lerna支持按照拓撲排序規則執行命令, --sort參數能夠控制以拓撲排序規則執行命令

lerna run --stream --sort build
複製代碼

OK！收工！歡迎你們持續關注咱們，咱們會保證至少周更1期前端內容，但願你們能提出寶貴建議，不要成爲失聯人口啊~