為什么大廠都要開發(fā)自己的腳手架？

    

     
    
    

     大廠技術(shù)  高級前端  Node進階
    
點擊上方 程序員成長指北，關(guān)注公眾號
回復(fù)1，加入高級Node交流群

作者：猿猴望月

原文：https://juejin.cn/post/7128597557634138148

每個初入大廠的前端同學(xué)，在真正投入開發(fā)之前的第一件事可能就是熟悉公司的腳手架，從那一刻起，你就拋棄了熟悉的cra、vue-cli、vite等，成為了合格的大廠人（誤）

大廠是不是為了沖績效所以才會開發(fā)腳手架呢？每當(dāng)新技術(shù)出現(xiàn)，作為熱愛技術(shù)的前端人我們難道就不想折騰折騰讓自己的項目“現(xiàn)代”起來？

我們可以從預(yù)開發(fā)環(huán)節(jié) ? 開發(fā)環(huán)節(jié) ? 構(gòu)建環(huán)節(jié) ? 預(yù)提交環(huán)節(jié) ? 發(fā)布環(huán)節(jié)，看看腳手架到底做了些什么。

本篇會做一些代碼的示意，但不會真正的寫一個腳手架出來。

預(yù)開發(fā)環(huán)節(jié)

簡化命令與配置

在沒有腳手架的時候，我們是怎么配置一個項目的呢？我們需要在項目中創(chuàng)建wekpack.config.js / rollup.config.js文件，基于開發(fā)和生產(chǎn)環(huán)境做各自的配置。

如果用到了一些別的工具，如esbuild等，又得增加一個別的配置文件，而像eslint、prettier、jest這些也都有各自的配置文件。而具體使用的時候，各個工具又各自需要各自的命令。

每次都記這一堆命令和配置對開發(fā)者來說是一件非常麻煩的事情，這也是腳手架對開發(fā)者來說最大的意義，它能夠很大程度上簡化我們需要的命令和配置。

而我們是怎么使用腳手架的呢？拿vite為例，我們可以通過簡單的命令就創(chuàng)建出一個vite的項目。

輸入命令行，進行一些選擇就可以創(chuàng)建一個項目，不需要你去寫一大堆的配置文件，直接npm run dev就能跑起來；同時，直接npm run build就可以打包成生產(chǎn)環(huán)境的代碼。如果是大廠內(nèi)部的框架，甚至還可以集成大廠內(nèi)部的部署環(huán)境，跑一個npm run preview或者npm run deploy就可以預(yù)覽 / 部署。

如果我們要實現(xiàn)這樣的效果，首先我們需要在腳手架項目中預(yù)定義一些模板（類似react、react-ts、vue、vue-ts等），其次，我們要能在命令行中運行bin來進行項目創(chuàng)建，可以看看vite的源碼，在create-vite的package.json^[1]中

"bin": {
    "create-vite": "index.js",
    "cva": "index.js"
}

bin指定create-vite路徑，而在index.js中則是主要做了命令行參數(shù)讀取、拉取最新模板的操作，有興趣的同學(xué)可以自己閱讀一下。

同時，腳手架往往提供了自己的config文件，比如vite就提供了vite.config來統(tǒng)一配置內(nèi)部所使用到的工具。這要怎么實現(xiàn)呢？簡單來說就是在vite的bin中讀取了vite.config文件內(nèi)容，從而構(gòu)建出vite config對象，再根據(jù)這個vite config對象生成對應(yīng)的rollup config對象然后調(diào)用rollup。

相應(yīng)vite可以參考github.com/vitejs/vite…^[2] 中resolveConfig這一段

export async function resolveConfig(
  inlineConfig: InlineConfig,
  command: 'build' | 'serve',
  defaultMode = 'development'
): Promise<ResolvedConfig> {
  let config = inlineConfig
  let configFileDependencies: string[] = []
  let mode = inlineConfig.mode || defaultMode

  // some dependencies e.g. @vue/compiler-* relies on NODE_ENV for getting
  // production-specific behavior, so set it here even though we haven't
  // resolve the final mode yet
  if (mode === 'production') {
    process.env.NODE_ENV = 'production'
  }
  ...

限定版本，規(guī)避風(fēng)險

想象一下如果你是個毛子這個時候應(yīng)該有多絕望哈哈，公司有自己的腳手架可以限定死版本，減少某個包的作者一時興起或者被攻擊者入侵發(fā)布了有問題的新版本，而我們又在這時新起項目或者升級包導(dǎo)致業(yè)務(wù)掛掉的情況。

這里說的是減少，因為總有庫不是被包括在腳手架里的，這也是lock文件的存在意義。

開發(fā)環(huán)節(jié)

提供模板

腳手架可提供多套模板供用戶選擇，類似純js、純ts、vue3+ts。同時，對于一些網(wǎng)頁需要的通用配置元素，如favicon，title，preconnect link可以通過config的方式提供給用戶配置。

也可以先提供monorepo殼子的模板，在其中再進行項目的初始化。

約定式路由

在項目中，可以約定一個名為pages的文件夾，pages下的文件夾中的index默認為一個個page。在pages中如果給出404、500這樣的index，也可以方便地做一些做頁面錯誤catch的處理；并且可以在腳手架中默認集成動態(tài)引入組件。

在需要做單頁面維度的權(quán)限校驗的場景下，這時又分兩種提示方式：第一種是不該進的路由用戶無法進入，第二種是可以進入，但是給一個申請權(quán)限的弱提示。如果是想要第一種提示方式的話，約定式路由需要進入頁面后校驗沒有權(quán)限再跳出，體驗上會稍差一些。

集合微前端

現(xiàn)在的single-spa、qiankun等微前端框架都非常流行，腳手架可以提供一套有微前端框架的B端模板，直接用于給開發(fā)者生成。如果是在大公司內(nèi)部，往往對這些微前端框架本身也有一定的封裝，形成公司自己的微前端框架，但對于腳手架來說，做的事情還是一樣的，就是把微前端框架的部分封裝起來。在開發(fā)者使用的時候，開發(fā)者甚至不需要知道頁面是通過微前端的方式來加載的，就用普通寫組件的方式來寫就好。

提供可插拔的功能插件（權(quán)限、埋點、sentry等

腳手架可提供一些插件，供開發(fā)者選擇是否接入（插件和上part提到的feature flag各自的側(cè)重點是：通過feature flag提供的功能更多與構(gòu)建相關(guān)，而插件更多為開發(fā)以及一些附加平臺功能）。像是埋點、sentry都比較簡單好理解，我們這里來聊一下權(quán)限。

大廠尤其是內(nèi)部系統(tǒng)很多都是使用單點登錄進行登錄的，而如果訪問接口沒有權(quán)限一般會是401的錯誤碼，所以其實可以在權(quán)限插件中做統(tǒng)一的無權(quán)限的登錄跳轉(zhuǎn)。

權(quán)限插件還可以做再細致的權(quán)限校驗，我們可以結(jié)合menu封裝，對每一個頁面進行業(yè)務(wù)邏輯上的可見的設(shè)置。

網(wǎng)絡(luò)請求層面封裝

腳手架一般會根據(jù)當(dāng)前的運行環(huán)境進行網(wǎng)絡(luò)請求方面的配置，比如dev、test、pre-release、production等，因為不同環(huán)境的請求baseURL、超時時間會不同。

同時，腳手架還可以提供基于接口定義生成接口定義代碼的功能，通過后端提供的swagger/thrift文件直接生成接口請求代碼。

prettier、eslint

每個大廠都會有自己對prettier和eslint的要求，將prettier和eslint的配置可以統(tǒng)一收口在腳手架中，形成一套代碼風(fēng)格。

構(gòu)建環(huán)節(jié)

構(gòu)建打包支持

腳手架往往提供開箱即用的構(gòu)建打包工具支持，對于前端常見的文件類型提供了默認配置，一般包括：

1. ts、js
2. css / less / sass / stylus / postcss / css module / tailwind支持，有的腳手架甚至提供了默認的換膚配置
3. 圖片、svg（包括導(dǎo)入為src或組件直接渲染）
4. wasm等等

避免重復(fù)造輪子

這里的重復(fù)造輪子更多指的是性能優(yōu)化層面，首先腳手架一般都有持續(xù)迭代的同學(xué)，當(dāng)新技術(shù)出來時（比如vite、esbuild、swc等），可以先進行一波升級并推出beta版本或者提供出一個feature flag，減少真正產(chǎn)出業(yè)務(wù)的同學(xué)重復(fù)踩坑的可能。

這里提供一個swc的feature flag供大家參考：

/**
 * config sample
 * swc: { jsc: { parser: { syntax: "typescript", tsx: true } } }
 */
if (options?.swc) {
  return {
    test: /\.(t|j)sx?$/,
    use: {
      loader: "swc-loader",
      options:
        typeof options.swc === "object"
          ? options.swc
          : transformTsConfigToSwcConfig(),
    },
    exclude: /node_modules/,
  };
} else {
  return {
    test: /\.(t|j)sx?$/,
    use: {
      loader: "babel-loader",
    },
    exclude: /node_modules/,
  };
}

預(yù)提交環(huán)節(jié)

commit hook

腳手架中可以集成git commit之前觸發(fā)的鉤子，鉤子中主要可以做：

1. commit message的check，例如項目是monorepo結(jié)構(gòu)，那commit message應(yīng)該是feat/fix/chore……(project name): xxx改動，可以采用commitlint - Lint commit messages^[3]
2. 代碼質(zhì)量的初步校驗，eslint、prettier的強校驗

這里不建議在commit hook中做過于重的校驗，因為commit時希望hook能夠較快執(zhí)行完，讓用戶還是可以盡快提交。更全的校驗還是放在CI階段執(zhí)行，如unit test等。

發(fā)布環(huán)節(jié)

push結(jié)合CI

在預(yù)提交環(huán)節(jié)，我們提到了用commit hook做初步校驗，但是hook總是有方法繞過的，所以在CI時還是要做double-check。

一般腳手架會提供一個ci yml文件來靈活的控制構(gòu)建，在push代碼可以進行CI，一旦CI有問題后續(xù)的合入或者CD都不可再繼續(xù)。

發(fā)正式版本可以在本地用腳手架publish，也可以在畫面CI時直接提供打正式包的選項。

最后

Node 社群

    

     

      

       

        

       
       

        

       
      
     
    
我組建了一個氛圍特別好的 Node.js 社群，里面有很多 Node.js小伙伴，如果你對Node.js學(xué)習(xí)感興趣的話（后續(xù)有計劃也可以），我們可以一起進行Node.js相關(guān)的交流、學(xué)習(xí)、共建。下方加 考拉 好友回復(fù)「Node」即可。
   “分享、點贊、在看” 支持一下