摘要：歷史上由于是作為的替代品出現(xiàn)，當(dāng)時(shí)要解決的問題是處理瀏覽器兼容問題，打包或，做一些公共資源替換，雪碧圖等，最后可以順帶合并到一個(gè)文件，但模塊化功能遠(yuǎn)遠(yuǎn)比弱，基本上只能合并，但不能理解模塊概念。

說到前端編譯方案，也就是如何打包項(xiàng)目，如何編譯組件，可選方案有很多，比如：

通過 webpack / parcel / gulp 構(gòu)建項(xiàng)目。

通過 parcel / gulp / babel 構(gòu)建組件。

如果你喜歡零配置的 parcel，那么項(xiàng)目和組件都可以拿它來編譯。

如果你業(yè)務(wù)比較復(fù)雜，需要使用 webpack 做深度定制，那么常見組合是：項(xiàng)目 - webpack，組件 - gulp。

但項(xiàng)目與組件的編譯存在異同點(diǎn)，不同構(gòu)建工具支持的生態(tài)也存在異同點(diǎn)。

babel 一般不會(huì)解析模塊，也就是一般僅做代碼預(yù)處理，而不會(huì)改變文件結(jié)構(gòu)，也對(duì) require、import 語句不敏感。

webpack / parcel 主要就是解決模塊化打包問題，因?yàn)闉g覽器還不支持（現(xiàn)在部分支持 type="module"）。

gulp 理論上可以將 babel、webpack、parcel 作為插件，但這是后來的事。歷史上由于 gulp 是作為 grunt 的替代品出現(xiàn)，當(dāng)時(shí)要解決的問題是處理瀏覽器兼容問題，打包 scss 或 less，做一些公共資源替換，雪碧圖等，最后可以順帶合并到一個(gè)文件，但模塊化功能遠(yuǎn)遠(yuǎn)比 webpack 弱，基本上只能合并，但不能 “理解模塊概念”。

項(xiàng)目構(gòu)建的目的主要在于發(fā)布 CDN，所以大家一般不在乎構(gòu)建腳本的通用性。換句話說，無論項(xiàng)目使用了怎樣的構(gòu)建方式，怎樣理解 import 語句，甚至寫出 require.context 等自定義語法，只要最終編譯出符合瀏覽器規(guī)范的代碼（考慮到兼容性）就足夠。

組件構(gòu)建的目的主要在于發(fā)布 NPM，除了 ESNext 規(guī)范會(huì)使用 Babel 編譯成 ES3，大部分代碼寫的很收斂，甚至對(duì) SASS 的使用都要與 Typescript 插件一起組合成復(fù)雜的 Gulp Task。

所以往往大家會(huì)對(duì)項(xiàng)目采取復(fù)雜的構(gòu)建約束策略，而對(duì)組件的編譯采取相對(duì)簡(jiǎn)單的辦法，確保發(fā)布代碼的通用性。

所以在大部分項(xiàng)目使用 webpack 支持 worker-loader 時(shí)，編寫組件時(shí)發(fā)現(xiàn)這段代碼不靈了。或者至少你得付出一些代價(jià)，因?yàn)榻M件的調(diào)試依然可以利用 webpack-dev-server，這時(shí)可以加上 worker-loader，但由于 gulp 沒有靠譜的 worker 插件，你的組件可能需要將 Worker 引用部分原樣輸出，希望由引用它的項(xiàng)目做掉對(duì) worker-loader 的支持。

其實(shí)這種心態(tài)是很危險(xiǎn)的，不僅導(dǎo)致了組件不通用，甚至引發(fā)了各構(gòu)建工具的 Tree Shaking 優(yōu)化。原因就是構(gòu)建組件的代碼太原始，冗余的代碼沒有刪除，甚至直接引用的 SASS 代碼仍然保留，更危險(xiǎn)的是帶上了一些特殊 webpack loader 才支持的語法。

之所以說 Antd 是一個(gè)擁有優(yōu)秀基因的前端組件庫，是因?yàn)樗裱饲岸私M件最基本的代碼素養(yǎng)：

編譯后的代碼全部符合基本 JS 規(guī)范，換個(gè)角度來說，使用 webpack 內(nèi)置基本 js loader 就能完全解析。

將 css 代碼抽離出來，這樣不會(huì)強(qiáng)制項(xiàng)目對(duì) node_modules 的代碼應(yīng)用 css-loader。

所以一個(gè) 靠譜的組件庫 的產(chǎn)出文件，應(yīng)該符合基本 ES 模塊化規(guī)范，且不包括任何特殊語法。

但是這引發(fā)了一個(gè)新的問題：組件開發(fā)體驗(yàn)比項(xiàng)目差很多。

比如組件想使用雪碧圖自動(dòng)優(yōu)化、想使用 worker-loader 方便快捷的調(diào)用多線程，想用自己的 css modules，甚至想把項(xiàng)目里一堆 PostCSS 快捷語法搬過來時(shí)怎么辦？難道組件開發(fā)就不能獲得與項(xiàng)目開發(fā)一樣的體驗(yàn)嗎？

要解決這個(gè)問題，筆者介紹一種基于 webpack 的通用構(gòu)建方案，讓本地調(diào)試、CDN 打包、ES6 -> ES3 轉(zhuǎn)換 都使用統(tǒng)一套配置代碼，同一套 loader。

核心思想只有一句話：利用 webpack-node-externals 忽略 Webpack 對(duì)指向 node_modules 的 require 或 import 語句：

進(jìn)行項(xiàng)目/組件調(diào)試時(shí)，開啟 development 模式。

進(jìn)行項(xiàng)目編譯時(shí)，開啟 production 模式。

進(jìn)行組件編譯時(shí)，開啟 production 模式，且利用 webpack-node-externals 插件忽略 node_modules。

可以想像，根據(jù)第三條，如果所有組件都按照這個(gè)模式輸出代碼，那么 webpack 對(duì) node_modules 編譯時(shí)，只需要將所有 require 代碼進(jìn)行合并，不需要執(zhí)行任何 loader，也不需要壓縮，不需要 TreeShaking，因?yàn)檫@些在組件代碼編譯時(shí)全部已經(jīng)做好了，這種構(gòu)建效率幾乎達(dá)到最大。

我們拿支持 typescript、sass、css-modules、worker-loader 的場(chǎng)景作為案例。

我們創(chuàng)建三個(gè)文件 entry.tsx entry.worker.ts 與 entry.scss：

entry.scss:

.container {
  border: 1px solid #ccc;
}

.primary {
  color: blue;
  &:hover {
    color: green;
  }
}

entry.worker.ts:

import hello from "hello";

const ctx: Worker = self as any;

ctx.onmessage = event => {
  ctx.postMessage(hello());
};

export default null as any;

entry.tsx:

import * as React from "react";
import styles from "./entry.scss";
import * as MyWorker from "./parser.worker";

const worker = new MyWorker();

export default () => (
  

    Click Me.
  
);

在上面三個(gè)文件中，我們分別利用了 Typescript 編譯、SCSS 編譯、css-modules 解析、worker-loader 解析（利用 webpack 自動(dòng)生成字符串代碼并利用 Blob URL 方式載入，這樣就不需要?jiǎng)?chuàng)建新文件也可以用 worker 了，也不會(huì)存在跨域問題）。

為了支持這幾個(gè)特性對(duì)如上代碼做調(diào)試、項(xiàng)目發(fā)布、組件發(fā)布，我們分別看下這三個(gè)場(chǎng)景該如何配置編譯腳本。

本地調(diào)試是不用區(qū)分組件與項(xiàng)目的。因?yàn)闊o論何種情況，都需要進(jìn)行基本的項(xiàng)目編譯，載入所有自定義 loader 并打成一個(gè) bundle 包。

此時(shí)我們只要維護(hù)一份 webpack 配置即可：

const webpackConfig = {
  mode: "development",
  module: {
    rules: [
      {
        test: /.worker.tsx?$/,
        use: {
          loader: "worker-loader",
          options: {
            inline: true
          }
        },
        include: path.join(projectRootPath, "src")
      },
      {
        test: /.tsx?$/,
        use: [
          [
            "babel-loader",
            {
              plugins: [
                [
                  "babel-plugin-react-css-modules",
                  {
                    filetypes: {
                      ".scss": {
                        syntax: "postcss-scss"
                      }
                    }
                  }
                ]
              ]
            }
          ],
          "ts-loader"
        ],
        include: path.join(projectRootPath, "src")
      },
      {
        test: /.scss$/,
        use: [
          "style-loader",
          [
            "css-loader",
            {
              importLoaders: 1,
              modules: true
            }
          ],
          "sass-loader"
        ],
        include: path.join(projectRootPath, "src")
      }
    ]
  }
};

export default webpackConfig;

利用這個(gè)配置加上 webpack-dev-server 即可完成組件與項(xiàng)目的本地調(diào)試。

項(xiàng)目發(fā)布時(shí)，需要將所有代碼打入到一個(gè) bundle 包，此時(shí)只需使用 webpack-cli 即可，對(duì)配置做如下修改：

export default {
  ...webpackConfig,
  mode: "production"
};

組件發(fā)布時(shí)，依然使用 webpack-cli 構(gòu)建，但利用 webpack-node-externals 忽略對(duì) node_modules 的解析。

import * as nodeExternals from "webpack-node-externals";

export default {
  ...webpackConfig,
  mode: "production",
  externals: [nodeExternals()]
};

此時(shí)編譯的組件代碼，包含了 Typescript 編譯、SCSS 編譯、css-modules 解析、worker-loader 解析，但所有 node_modules 代碼都保持原樣，比如下面的代碼：

做了代碼去重、按需加載、打包、壓縮，但因?yàn)楸３至?require 原樣，因此大小只有源碼體積。

同時(shí)上述三個(gè)場(chǎng)景都在復(fù)用 webpack 一套代碼的基礎(chǔ)上，利用了 webpack 的生態(tài)，因此維護(hù)性和拓展性都很強(qiáng)。后續(xù)再加入新功能，再也不需要到處找 babel 或 gulp 的插件了！

本文從 webpack 為切入點(diǎn)，但其實(shí)還可以從 parcel 或 gulp 為切入點(diǎn)，實(shí)現(xiàn)前端項(xiàng)目、組件構(gòu)建體系的統(tǒng)一。

不過從可定制性來看，webpack 插件生態(tài)更完善，所以筆者選擇了 webpack。

留下一個(gè)思考題：你的項(xiàng)目、組件是如何構(gòu)建的呢？是用了一套代碼，還是兩套呢？

討論地址是：精讀《如何編譯前端項(xiàng)目與組件》 · Issue #125 · dt-fe/weekly

如果你想?yún)⑴c討論，請(qǐng)點(diǎn)擊這里，每周都有新的主題，周末或周一發(fā)布。前端精讀 - 幫你篩選靠譜的內(nèi)容。