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