前端提效：使用「工程方案」代替「腳手架」

做者：字節跳動Web Infra —— 張水生

腳手架的演變

在前端研發活動中，腳手架負責項目的初始化工做，是後續研發活動的基礎。一個典型的研發活動流程大概是這樣：執行腳手架建立項目 -> 開發 -> 構建 -> 測試 -> 部署。

團隊規模較小或者業務比較簡單的時候，可能也用不上腳手架，比較常見的項目初始化方式是直接從一個已有的項目中拷貝一份出來，而後酌情刪除業務相關代碼，保留和修改基礎代碼。

若是業務發展比較快，隔段時間就須要新建一個項目，這種方式無疑比較繁瑣，因而有了第二種方式。把上一種方式造成的模板代碼上傳到倉庫中維護起來，須要新建項目時，將倉庫代碼 clone 出來，刪除 .git 目錄，從新上傳到新項目的倉庫。並且後續能夠持續迭代這個模板倉庫，維護性更好。

每次新建項目都須要走一遍以下過程： clone 代碼 -> 刪除 .git 目錄 -> 關聯並 push 到新倉庫，略顯繁瑣，因而有了第三種方式。將這個過程封裝成 CLI 命令，好比叫作 fe-cli ，每次須要新建項目只須要執行 fe-cli projectName 便可。得益於 Node.js 生態的繁榮，封裝這個 CLI 並不難，只需綜合運用好相關庫便可（如 commander inquirer shelljs 等）。更進一步，能夠在這個 CLI 裏實現模板選擇功能，這樣的話，就能夠支持不一樣類型的項目建立了。

腳手架的維護成本

用完即拋

一個顯而易見的問題是，若是不是專門作基建的團隊，花費時間和人力成本維護這樣一個腳手架彷佛有點得不償失。腳手架的功能作得再豐富，交互性再好，也只是用來建立項目，生成一堆模板代碼，項目建立好了就放置一邊，等到下次建立纔會再撿起來。

版本升級

還有一個比較麻煩的問題是，若是腳手架作了升級，除非在腳手架裏面強制檢測版本並要求用戶升級，不然用戶使用腳手架新建項目時，大機率可能用的是上次安裝時的版本。辛苦更新的功能無法及時讓用戶使用上，很是尷尬。一個可能的解決辦法是要求用戶使用 npx 來代替 npm i -g ，這種方式無疑爲使用增長了一點小成本。

工程方案 - 代碼初始化

在 「Goofy Studio」(字節內部的一體化前端研發工做臺，能夠覆蓋前端研發的全部活動，好比應用的建立，開發，構建，部署以及雲 IDE 等) 裏，咱們給出的解決辦法是「工程方案」。

「工程方案」不單純是「腳手架」的升級版，而是一系列前端研發活動「最佳實踐」的沉澱。工程方案包含多種配置，其中的「代碼初始化配置」即涵蓋了「腳手架」的功能。

咱們提供了三種代碼初始化方式：模板方式，雲端 CLI 方式，webshell 方式。其實工程方案的代碼初始化也是作了初始代碼生成，新建倉庫，push 代碼等操做，與在本機執行腳手架並沒有大的不一樣。可是，工程方案的代碼初始化徹底是在雲端容器執行的，最大程度的避免了本地環境差別形成的失敗問題，且過程全自動，無需人工干預，大大節省時間。

更妙的是，工程方案的項目建立能夠一次性將各類服務（好比構建服務節點，部署服務節點等）及發佈流水線建立好，項目建立完成後便可進行發佈，對於新人來講很是友好，對於資深的老人來講也很是省心。

因爲本文主要闡述如何替換腳手架，所以工程方案的其餘部分很少作介紹。

模板方式

這種方式是最簡潔的，只需配置一個模板代碼壓縮包(tar)便可，代碼初始化時會直接將該壓縮包上傳到新建立的倉庫。

雲端 CLI 方式

這種方式會在一個容器裏執行設置好的命令以進行代碼初始化，並將產物做爲模板代碼上傳到新建立的倉庫。這個過程各個環節都可配置，好比全局安裝的包，執行的命令，產物的目錄，須要忽略的文件及文件夾等。

下圖是建立一個 Vue 項目的代碼初始化配置。因爲編譯平臺經過配置文件(scm_build.sh)來定義編譯過程，所以咱們提供了 @byted/studio-cli 來生成該配置文件。

上圖使用-p default 生成了一個最簡單的 Vue 項目，可是實際業務中可能須要開啓內置的一些功能，好比 Vuex babel 等。所以咱們提供了「schema 輸入表單」來支持用戶在初始化時向 CLI 傳遞數據。 爲了演示 schema，咱們再生成一個Gulu 工程 (Gulu 是內部使用的一種開發框架)，而且提供模板選擇功能，代碼初始化部分配置以下圖：

爲了能渲染出上圖中的模板選擇下拉菜單，咱們須要配置 schema：

{
  "schema": {
    "key": "gulu",
    "isObject": true,
    "items": [
      {
        "key": "template",
        "label": "select template",
        "items": [
          {
            "key": "http-server",
            "label": "http-server"
          },
          {
            "key": "http-server-ts",
            "label": "http-server-ts"
          },
          {
            "key": "thrift-server",
            "label": "thrift-server"
          },
          {
            "key": "thrift-server-ts",
            "label": "thrift-server-ts"
          },
          {
            "key": "plugin",
            "label": "plugin"
          },
          {
            "key": "plugin-ts",
            "label": "plugin-ts"
          }
        ]
      }
    ]
  },
  "customUIConfig": {
    "template": {
      "ui": "Select"
    }
  }
}
複製代碼

該部分的 schema 語法，採用了咱們本身研發的一套動態表單方案。

webshell 方式

爲了進一步下降代碼初始化的配置門檻，咱們也開發了 webshell 方式，即不須要配置任何 schema 表單，只須要配置 CLI 命令。執行代碼初始化過程時，用戶能夠直接在頁面的 webshell 上進行交互，徹底模擬 CLI 在本機執行的過程。

webshell 方式也會做爲 CLI 方式的兜底，即便 CLI 升級了，增長了一些問題，而 schema 沒有及時更新，用戶也能夠在 webshell 裏完成新增的問題交互，成功進行代碼初始化。

小結

使用工程方案的代碼初始化配置來代替腳手架，使得每次建立項目時使用的都是最新版的 CLI，並且每次都在一個全新的容器裏進行，可最大程度提升代碼生成成功率。

工程方案市場

前面說到「工程方案」是前端研發活動「最佳實踐」的沉澱，所以咱們作了「工程方案市場」，將「最佳實踐」以實體的方式提供出來，任何人能夠直接使用。

將團隊定製的工程方案放到工程方案市場裏，一方面方便團隊的業務開發，維持技術的統一性，另外一方面也能夠向外輸出影響力。

關於字節終端技術團隊

字節跳動終端技術團隊(Client Infrastructure)是大前端基礎技術的全球化研發團隊（分別在北京、上海、杭州、深圳、廣州、新加坡和美國山景城設有研發團隊），負責整個字節跳動的大前端基礎設施建設，提高公司全產品線的性能、穩定性和工程效率；支持的產品包括但不限於抖音、今日頭條、西瓜視頻、飛書、瓜瓜龍等，在移動端、Web、Desktop等各終端都有深刻研究。

就是如今！客戶端／前端／服務端／端智能算法／測試開發 面向全球範圍招聘！一塊兒來用技術改變世界，感興趣能夠聯繫郵箱 chenxuwei.cxw@bytedance.com，郵件主題 簡歷-姓名-求職意向-指望城市-電話。