摘要：文章同步在微店前端工程化起步于一個(gè)內(nèi)部產(chǎn)品，對(duì)外我們有一個(gè)開(kāi)源版本。這么長(zhǎng)時(shí)間過(guò)去了，我們?cè)谇岸斯こ袒矫嬗辛四男┳兓龅搅四男﹩?wèn)題用怎樣的方案解決這些問(wèn)題等等，值得為大家再分享。最終產(chǎn)品以命令行的形式發(fā)布。

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

微店前端工程化起步于一個(gè)內(nèi)部產(chǎn)品 vbuilder，對(duì)外我們有一個(gè)開(kāi)源版本 bio-cli。

去年我們也寫(xiě)過(guò)一篇文章介紹該產(chǎn)品： bio: 一站式前端開(kāi)發(fā)工具。

這么長(zhǎng)時(shí)間過(guò)去了，我們?cè)谇岸斯こ袒矫嬗辛四男┳兓?、遇到了哪些?wèn)題、用怎樣的方案解決這些問(wèn)題等等，值得為大家再分享。

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

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

當(dāng)時(shí)，團(tuán)隊(duì)面臨幾個(gè)問(wèn)題：

重復(fù)：每個(gè)項(xiàng)目要新開(kāi)一個(gè)腳手架（webpack / gulp 之類）

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

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

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

協(xié)作：團(tuán)隊(duì)協(xié)作中，項(xiàng)目的技術(shù)棧紛雜，不同人員維護(hù)同一個(gè)項(xiàng)目成本高昂，如：需重新理解對(duì)應(yīng)工程配置等

總結(jié)為下圖：

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

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

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

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

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

靜默更新：用戶安裝一次命令即無(wú)需關(guān)注更新，其更新自行靜默完成

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

開(kāi)放接入腳手架：不限制技術(shù)棧類型（vue / react / angular / weex 等），開(kāi)放接入不同技術(shù)棧

插件化：除內(nèi)置命令集外，插件化擴(kuò)展命令集，供團(tuán)隊(duì)同學(xué)實(shí)現(xiàn)訂制邏輯

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

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

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

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

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

開(kāi)放：在收斂腳手架配置的同時(shí)，開(kāi)放性接入各類技術(shù)棧腳手架，如 weex / vms / 后臺(tái)管理 / serverside project 等

協(xié)作：團(tuán)隊(duì)統(tǒng)一性的技術(shù)更新得以快速進(jìn)行，不會(huì)再遇到因工程配置不同不斷適配的問(wèn)題

總結(jié)為下圖：

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

提效：幫助業(yè)務(wù)開(kāi)發(fā)者節(jié)省時(shí)間

共擔(dān)：開(kāi)發(fā)者參與生態(tài)建設(shè)（腳手架開(kāi)發(fā)維護(hù)、插件開(kāi)發(fā)），至少在績(jī)效上會(huì)得以加分

好用：使用方式簡(jiǎn)單好用，才讓人有用的欲望

V1.0 基本解決了以下角色的痛點(diǎn)：

后端同學(xué)：內(nèi)部系統(tǒng)開(kāi)發(fā)場(chǎng)景被 100% 覆蓋

前端同學(xué)：絕大部分業(yè)務(wù)場(chǎng)景被覆蓋

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

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

封閉性

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

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

此時(shí)，就必須新開(kāi)一個(gè)腳手架，重新接入 vbuilder 體系。

在 “開(kāi)放性” 來(lái)說(shuō)，打了折扣。

插件開(kāi)發(fā)的沖突

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

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

不過(guò)，V2.0 依然基于命令行。

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

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

當(dāng)然，會(huì)遇到腳手架難以統(tǒng)一管理的問(wèn)題，這一點(diǎn)仍然有辦法可以解決。

因?yàn)楸槐┞兜墓こ膛渲檬?vbuilder 提供的，vbuilder 得以方便地統(tǒng)計(jì)哪些項(xiàng)目使用了自定義的腳手架，將通用型工具包下發(fā)給該工程。

問(wèn)題 1：插件間的沖突

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

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

問(wèn)題 2：插件命令集與內(nèi)置命令的沖突

例如，內(nèi)置命令集中有命令 init，而某個(gè)插件也有 init。

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

怎樣解決？

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

vbuilder 檢測(cè)是否有重復(fù)命令，如有，提示用戶是都運(yùn)行、還是選擇運(yùn)行某一個(gè)插件中的命令

為命令圈定生效條件

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

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

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

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

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

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

定義內(nèi)置命令時(shí)，代碼如下：

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

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

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

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

在命令行這個(gè)場(chǎng)景下，我們把 vbuilder 定義為公司內(nèi)部開(kāi)發(fā)的一個(gè)“水電煤”性質(zhì)的基礎(chǔ)設(shè)施。

通過(guò) vbuilder，我們新增了以下場(chǎng)景：

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

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

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

支持快速打開(kāi)文檔庫(kù)等等

得益于插件化，通過(guò)充分調(diào)動(dòng)開(kāi)發(fā)者積極性，我們可以將其能力無(wú)限延展。

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

cloudIDE（內(nèi)部已有該類平臺(tái)）

vscode 定制化 IDE，該類場(chǎng)景在超大型團(tuán)隊(duì)比較適合，IDE 定制化開(kāi)發(fā)有更多的應(yīng)用場(chǎng)景，更快的開(kāi)發(fā)效率

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

這是目前我們?cè)谖⒌昵岸斯こ袒I(lǐng)域的一些實(shí)踐和思考，希望對(duì)大家有幫助。