Lerna + Dumi + Eslint多包管理實踐
背景
在開發大型項目時, 我們通常會遇到同一工程依賴不同組件包, 同時不同的組件包之間還會相互依賴的問題, 那么如何管理組織這些依賴包就是一個迫在眉睫的問題.
我們目前已有的方案有: Multirepo(多個依賴包獨立進行git管理) 和 Monorepo(所有依賴庫完全放入一個項目工程).
Multirepo的缺點在于每個庫變更之后，需要發布到線上，然后在項目中重新安裝, 打包, 發布, 最后才能更新，這樣如果依賴關系越復雜就越難以維護。Monorepo最大的缺點就是不便于代碼的復用和共享。
為了解決上述的問題, lerna 這款工具誕生了, 它可以方便的管理具有多個包的 JavaScript 項目。同時對于組件包的開發者和維護者, 為了讓團隊其他成員更好的理解和使用我們開發的組件, 搭建組件文檔和 demo 就顯得格外重要.
我們對以上提到的幾點問題做一個總結:
- 大型項目中如何管理組織依賴包及其版本問題
- 如何高效低成本的搭建簡單易用的組件文檔
- 如何配置eslint代碼規范和代碼提交規范
接下來我將針對以上問題一一來給出解答. 如果大家想看實際的案例, 可以參考:
- best-cps | 基于lerna + dumi搭建的多包管理實踐
大型項目中如何管理組織依賴包及其版本問題
這個問題主要用我上面的提到的 lerna 工具來解決. 目前我們比較熟悉的 babel, create-react-app, vue-cli 等都使用了 lerna.
在沒使用 lerna 時, 我們不同庫的組織形式可能如下:
使用 lerna 之后的庫組織結構:
以上兩個是我做的簡圖, 基本可以對比出使用 lerna 前后的差異, lerna 的作用是把多個項目或模塊拆分為多個 packages 放入一個git倉庫進行管理。我們可以使用它提供的命令輕松的對不同項目進行管理 , 如下:
- lerna boostrap 自動解決packages之間的依賴關系，對于packages內部的依賴會直接采用symlink的方式關聯
- lerna publish 依賴git檢測文件改動，自動發布，管理版本號
- lerna create 創建一個 lerna 管理的package包
- lerna clean 刪除所有包下面的node_modules目錄，也可以刪除指定包下面的node_modules
同時 lerna 還會根據 git 提交記錄，自動生成 changelog. 當然 lerna 還提供了很多有用的命令, 大家感興趣可以在官網學習.
接下來我就帶大家從零搭建一個使用 lerna 管理的多包項目.
上圖是我們包的依賴關系, 首先我們需要全局安裝一下 lerna.
項目初始化
- $ git init best-cps && cd best-cps
- $ lerna init
創建三個 package
- $ lerna create LibA && lerna create LibB && lerna create BaseUI
創建的每個包的目錄結構如下:
- LibA
- ├─ tests
- │ └─ dooring.test.js
- ├─ lib
- │ └─ dooring.js
- ├─ README.md
- └─ package.json
安裝對應包的依賴
由上文展示的3個包的依賴關系, 我們需要針對性的安裝, 如下:
- $ lerna add LibA --scope=LibB
因為 LibB 依賴 LibA, 所以我們使用 lerna add 時可以通過 --scope 來指定安裝范圍. 再比如 BaseUI 同時依賴LibA, LibB 兩個包, 我們可以使用如下命令:
- $ lerna add LibA LibB --scope=BaseUI
剩下的我們都可以按照上述的方式進行, 當我們編寫完對應包的代碼后, 我們還可以使用:
- $ lerna publish
一鍵將包發布到 npm 上, 此處根據我們選擇的管理模式不同，所有 packages 的版本號都會根據lerna.json中的版本號進行更新。但我們需要注意的是 lerna 版本更新支持兩種模式:
- 固定/鎖定模式(默認, 指定版本號)
這種模式自動將所有 packages 包版本捆綁在一起，對任何其中一個或者多個 packages 進行重大改動都會導致所有 packages 的版本號進行更新。
- 獨立模式(independent)
獨立模式，init的時候需要設置選項--independent。這種模式允許使用者對每個package單獨改變版本號。每次執行lerna publish的時候，針對所有有更新的package，會逐個詢問需要升級的版本號，基準版本為它自身的package.json里面的版本號。這種情況下，lerna.json的版本號不會變化， 默認為independent。我們可以在 lerna 初始化時指定:
- lerna init --independent
具體的案例可以參考: https://github.com/MrXujiang/best-cps
如何高效低成本的搭建簡單易用的組件文檔
對于組件文檔, 市面上也有很多開源的工具, 比如 vue-press, storybook, docz等, 因為我最近的項目多為 react, 這里我使用的是 dumi. 之前在分享實現滑動驗證碼組件的時候已經和大家分享的 dumi的使用, 大家可以參考我之前的文章:
- 從零開發一款輕量級滑動驗證碼插件
以下是在 lerna 項目中集成 dumi 后的文檔站點效果:
如何配置eslint代碼規范和代碼提交規范
eslint 代碼規范我想每個朋友都不陌生, 我們只需要安裝對應的插件并編寫對應規則的配置文件即可, 這里舉一個簡單的例子:
- // .eslintrc.js
- module.exports = {
- extends: [require.resolve('@umijs/fabric/dist/eslint')],
- rules: {
- 'import/no-extraneous-dependencies': 0,
- 'import/no-unresolved': 0,
- },
- };
配置好之后我們需要設置檢測時機, 比如說時運行時檢測還是提交時檢測, 由于個人習慣和效率問題, 我采用了提交時檢測, 也就是當開發者功能開發完成, 執行 git commit 的時候進行檢測, 我們可以利用 githook 來做預提交檢測, 這里需要在 package.json 文件中添加如下命令:
- "gitHooks": {
- "pre-commit": "npm run lint:js"
- },
配置好之后我們隨便寫一行不合規范的代碼, 然后提交, 終端會顯示如下信息:
從控制臺可以發現代碼不合規范的位置和原因, 如果我們沒有做出調整, 代碼就無法提交, 通過這樣的方式可以提高代碼質量和出錯概率, 非常有長遠價值.
同時上面提到了 githooks, 對于 githooks 的知識也非常有意思, 它可以幫我們在代碼提交的不同階段進行自定義操作, 比如代碼提交前的檢測, 代碼提交信息規范等進行校驗, 常用的 gtihooks 有:
- pre-commit
- prepare-commit-msg
- commit-msg
- post-commit
- pre-rebase
- post-merge
- pre-receive
- update
大家感興趣的可以訪問 https://githooks.com 獲取更多有關 githooks的內容.
對于代碼提交規范, 我們也需要做統一管理, 這樣能讓團隊更直觀的知道每一次提交的內容是什么, 尤其是多人協作的時候. 以下是幾個常見的提交不規范的例子:
- git commit -m '添加彈窗'
- git commit -m ':update 更新'
- git commit -m 'fix 修復一個bug'
之所以會存在以上提交格式不統一或者提交信息難懂的問題, 都是因為缺少了規范的制約, 所以說對于大型項目或者多人協作的項目, 最好還是統一規范, 這樣能提前避免很多不必要的麻煩.
要想實現對工程師提交信息的檢測, 需要用到 commit-msg 這個 githooks, 具體配置如下:
- "gitHooks": {
- "pre-commit": "npm run lint:js",
- "commit-msg": "node ./commitlint.js verify-commit"
- }
剩下的就是 commitlint.js 做的事情了, 它是我編寫的一個 nodejs 腳本, 用來檢測用戶提交的信息是否規范, 當然大家也可以基于這個腳本定義自己的提交規范, 具體效果如下:
我們可以看到, 當我們提交了一個不符合規范的信息之后, 終端控制臺會打印如下提示信息并終止程序繼續進行.
通過以上的配置, 團隊不同成員的寫的代碼和提交信息都會非常統一和規范, 項目整體的質量也會得到一定的提升.
以上基于 lerna + dumi + eslint + commit 實踐我已經發布到 github, 大家可以參考學習一下, 歡迎提出更好的建議.
