摘要：文章同步在微店前端工程化起步于一個內部產品，對外我們有一個開源版本。這么長時間過去了，我們在前端工程化方面有了哪些變化遇到了哪些問題用怎樣的方案解決這些問題等等，值得為大家再分享。最終產品以命令行的形式發(fā)布。

文章同步在：https://github.com/hoperyy/bl...

微店前端工程化起步于一個內部產品 vbuilder，對外我們有一個開源版本 bio-cli。

去年我們也寫過一篇文章介紹該產品： bio: 一站式前端開發(fā)工具。

這么長時間過去了，我們在前端工程化方面有了哪些變化、遇到了哪些問題、用怎樣的方案解決這些問題等等，值得為大家再分享。

這里也就是介紹下背景，為什么我們會開發(fā) vbuilder。

總體思路就是：將重復性工作集成化。

當時，團隊面臨幾個問題：

重復：每個項目要新開一個腳手架（webpack / gulp 之類）

混雜：工程目錄既包含腳手架文件，也包含業(yè)務文件

混雜：packge.json 中的依賴既有腳手架的依賴，也有業(yè)務依賴，難以區(qū)分

難更新：腳手架一旦確定，幾乎不再更新，如 webpack 1.0 的項目極有可能會一直維持在 webpack 1.0 狀態(tài)

協(xié)作：團隊協(xié)作中，項目的技術棧紛雜，不同人員維護同一個項目成本高昂，如：需重新理解對應工程配置等

總結為下圖：

基于以上問題，我們開始了 vbuilder 的研發(fā)。

最終產品以命令行的形式發(fā)布。

此時的 vbuilder 為 V0.0 狀態(tài)。

vbuilder V1.0 提供了以下能力：

默認命令集：內置一套命令集，用于常見功能開發(fā)，包括 mock / update / help 等

靜默更新：用戶安裝一次命令即無需關注更新，其更新自行靜默完成

收斂腳手架：將工程內的腳手架配置隱藏，并統(tǒng)一管理，開發(fā)者可快速聚焦業(yè)務邏輯

開放接入腳手架：不限制技術棧類型（vue / react / angular / weex 等），開放接入不同技術棧

插件化：除內置命令集外，插件化擴展命令集，供團隊同學實現(xiàn)訂制邏輯

vbuilder 的不斷推進下，我們欣喜地看到，團隊發(fā)生了一些變化：

便捷：新項目一個命令即創(chuàng)建，直接開始業(yè)務開發(fā)

純粹：工程目錄只保留了業(yè)務文件，腳手架等工程配置被隱藏

更新：腳手架被收斂為統(tǒng)一管理，統(tǒng)一更新，盡可能應用最新的技術棧

協(xié)作：絕大部分項目協(xié)作的成本范圍收斂到 “業(yè)務邏輯”，剔除了 “工程配置邏輯”，協(xié)作成本大大降低

開放：在收斂腳手架配置的同時，開放性接入各類技術棧腳手架，如 weex / vms / 后臺管理 / serverside project 等

協(xié)作：團隊統(tǒng)一性的技術更新得以快速進行，不會再遇到因工程配置不同不斷適配的問題

總結為下圖：

V1.0 出現(xiàn)后，推進的很順利，在推進過程中秉持如下原則：

提效：幫助業(yè)務開發(fā)者節(jié)省時間

共擔：開發(fā)者參與生態(tài)建設（腳手架開發(fā)維護、插件開發(fā)），至少在績效上會得以加分

好用：使用方式簡單好用，才讓人有用的欲望

V1.0 基本解決了以下角色的痛點：

后端同學：內部系統(tǒng)開發(fā)場景被 100% 覆蓋

前端同學：絕大部分業(yè)務場景被覆蓋

腳手架開發(fā)者：強大的腳手架被開發(fā)好后，得以快速推廣

插件開發(fā)者：自定義命令，滿足個性化開發(fā)

封閉性

高度定制化的工程配置需求實現(xiàn)難度增大

腳手架配置的主題被隱藏，雖然仍然開放給開發(fā)者一些配置性文件，對于高度定制化的配置需求而言依然杯水車薪。

此時，就必須新開一個腳手架，重新接入 vbuilder 體系。

在 “開放性” 來說，打了折扣。

插件開發(fā)的沖突

由于 vbuilder 是基于命令行開發(fā)，插件開發(fā)者擴展自定義命令式，依然是自定義命令行，團隊規(guī)模不斷擴大的狀態(tài)下，很容易出現(xiàn)不同插件使用同一個命令，被同時安裝的狀態(tài)下，重復執(zhí)行該命令。

V2.0 至少要解決 V1.0 存在的問題，同時需要有更明確的發(fā)展方向。

不過，V2.0 依然基于命令行。

V1.0 的思路是 “閉合”，雖然有一定的開放性，但仍然不夠。

V2.0 新增 “開放” 的能力，腳手架配置可以被隱藏，也可以隨時在需要的時候暴露在工程配置中，進行定制化開發(fā)。

當然，會遇到腳手架難以統(tǒng)一管理的問題，這一點仍然有辦法可以解決。

因為被暴露的工程配置是 vbuilder 提供的，vbuilder 得以方便地統(tǒng)計哪些項目使用了自定義的腳手架，將通用型工具包下發(fā)給該工程。

問題 1：插件間的沖突

舉個例子，有兩個插件中，都有一個命令 run。如果用戶安裝了這兩個插件，在執(zhí)行 run 命令的時候，兩個插件的邏輯均會觸發(fā)。

在某些情況下，這不是用戶希望看到的場景，可能 TA 希望的只是運行插件 A 的命令 run。

問題 2：插件命令集與內置命令的沖突

例如，內置命令集中有命令 init，而某個插件也有 init。

那么在用戶執(zhí)行 init 命令時，依然會執(zhí)行兩遍邏輯。

怎樣解決？

我們組合使用了以下方案：

vbuilder 檢測是否有重復命令，如有，提示用戶是都運行、還是選擇運行某一個插件中的命令

為命令圈定生效條件

vbuilder 的命令行基于 commander。我們基于 commander 擴展了一些方法。

假如我們希望，插件中的命令 show 只在工程目錄中 xx.show 文件存在的情況下生效，那么代碼如下：

commander
.command("show [param]")
.effect(cwd  => fs.existsSync(path.join(cwd, "xx.show"))) ---- 這是我們擴展的命令
.description("我的自定義命令")
.action((param, options) => {
    console.log("my show");
});

為內置命令集聲明其為“內置命令”，插件命令可以阻止內置命令執(zhí)行

假如插件中有個命令 init，而 vbuilder 內置命令中也有 init，我們希望插件中的 init 命令生效，內置命令不生效，該怎么做呢？

我們擴展了 commander 的 2 個方法：declareDefault 聲明內置命令、preventDefault 阻止內置命令執(zhí)行。

定義內置命令時，代碼如下：

commander
.command("init [param]")
.declareDefault() --- 聲明內置命令
.description("內置的 init 命令")
.action((param, options) => {
    console.log("init inside");
});

開發(fā)插件命令時，代碼如下：

commander
.command("init [param]")
.preventDefault() --- 阻止內置命令執(zhí)行
.description("內置的 init 命令")
.action((param, options) => {
    console.log("init inside");
});

Commander 的源碼只有 1000 行左右，邏輯還是很清晰的，擴展起來非常方便，這里不再列舉實現(xiàn)。

在命令行這個場景下，我們把 vbuilder 定義為公司內部開發(fā)的一個“水電煤”性質的基礎設施。

通過 vbuilder，我們新增了以下場景：

支持 chrome 插件 es6/7 化開發(fā)

支持組件庫快速開發(fā)

支持 js 工具庫快速開發(fā)

支持快速打開文檔庫等等

得益于插件化，通過充分調動開發(fā)者積極性，我們可以將其能力無限延展。

我們目前還沒有進入 3.0 的開發(fā)，但有一些方向是我們可以嘗試的：

cloudIDE（內部已有該類平臺）

vscode 定制化 IDE，該類場景在超大型團隊比較適合，IDE 定制化開發(fā)有更多的應用場景，更快的開發(fā)效率

云化（其實不算新了，很多公司已經實現(xiàn)了云化）

這是目前我們在微店前端工程化領域的一些實踐和思考，希望對大家有幫助。