摘要：為何有查閱了的文檔，并沒(méi)有找到字段的定義，直到才知道它是中最早就提出的概念。況且目前大部分仍是采用，所以便使用了另一個(gè)字段。所以目前主流的打包工具都是支持的，鑒于其優(yōu)點(diǎn)，字段很有可能加入的規(guī)范之中。

最近團(tuán)隊(duì)的一個(gè)同學(xué)在搞 npm library 源碼的調(diào)試插件，因?yàn)閮?nèi)部的一個(gè)組件庫(kù)含有大量的邏輯，在某個(gè)項(xiàng)目中不經(jīng)意就出現(xiàn)一個(gè)磨人的 bug，但是組件庫(kù)發(fā)布都是打包編譯后的代碼，而且沒(méi)有 publish src 代碼，不方便調(diào)試，每次還要 down 一下包的源碼，再改下 webpack 的配置（比如 rule 中 exclude 去掉組件庫(kù)， 改下 resolve ，在 dll 中去掉組件庫(kù)）。被他們耳語(yǔ)目染了好幾天，我就想，記得 npm 包是可以直接引源碼的，大概改下 webpack 配置就可以了。然后便找到了 package.json 中 module 字段，并查漏 js 中 tree shaking 的知識(shí)，所以我并沒(méi)有去研究怎么搞那樣的一個(gè)插件?，而是由 package 中的 module 字段延伸出的一些知識(shí)。

查閱了 package.json 的文檔，并沒(méi)有找到 module 字段的定義，直到 google 才知道它是 rollup 中最早就提出的概念 --- pkg.module。大概就是最早的 npm 包都是基于 CommonJS 規(guī)范的，package.json 形如：

"name": "package1",
"version": "1.0.0",
"main": "lib/index.js"

當(dāng) require("package1") 的時(shí)候，就會(huì)根據(jù) main 字段去查找入口文件。
而 es2015 后，js 擁有了 ES Module，相較于之前的模塊化方案更爽滑，更優(yōu)雅，并且 ES 模塊也是官方標(biāo)準(zhǔn)（JS 規(guī)范），而 CommonJS 模塊是一種特殊的傳統(tǒng)格式，在 ES 模塊被提出之前做為暫時(shí)的解決方案。所以 rollup 去利用 ES Module 構(gòu)建，就可以利用 ES Module 的很多特性，從而提高打包的性能，其中提升一個(gè)便是 tree shaking，這個(gè)我們后面去介紹。在這個(gè)構(gòu)建思想的基礎(chǔ)上，開(kāi)發(fā)、產(chǎn)出的 npm 包同樣使用 es6 的 module，即可同樣受益于 tree shaking 等特性。

而 CommonJS 規(guī)范的包都是以 main 字段表示入口文件了，如果使用 ES Module 的也用 main 字段，就會(huì)對(duì)使用者造成困擾，假如他的項(xiàng)目不支持打包構(gòu)建，比如大多數(shù) node 項(xiàng)目(盡管 node9+ 支持 ES Module)。這就是庫(kù)開(kāi)發(fā)者的模塊系統(tǒng)跟項(xiàng)目構(gòu)建的模塊系統(tǒng)的沖突，更像是一種規(guī)范上的問(wèn)題。況且目前大部分仍是采用 CommonJS，所以 rollup 便使用了另一個(gè)字段：module。
像這樣：

"name": "package1",
"version": "1.0.0",
"main": "lib/index.js",
"module": "es/index.js"

webpack 從版本 2 開(kāi)始也可以識(shí)別 pkg.module 字段。打包工具遇到 package1 的時(shí)候，如果存在 module 字段，會(huì)優(yōu)先使用，如果沒(méi)找到對(duì)應(yīng)的文件，則會(huì)使用 main 字段，并按照 CommonJS 規(guī)范打包。所以目前主流的打包工具（webpack, rollup）都是支持 pkg.module 的，鑒于其優(yōu)點(diǎn)，module 字段很有可能加入 package.json 的規(guī)范之中。另外，越來(lái)越多的 npm 包已經(jīng)同時(shí)支持兩種模塊，使用者可以根據(jù)情況自行選擇，并且實(shí)現(xiàn)也比較簡(jiǎn)單，只是模塊導(dǎo)出的方式。

注意：雖然打包工具支持了 ES Module，但是并不意味著其他的 es6 代碼可以正常使用，因?yàn)槭褂谜呖赡懿⒉粫?huì)對(duì)你的 npm 包做編譯處理，比如 webpack rules 中 exclude: /node_modules/，所以如果不是事先約定好后編譯或者沒(méi)有兼容性的需求，你仍需要用 babel 處理，從而產(chǎn)出兼容性更好的 npm 包。還好 rollup 在這方面做的不錯(cuò)，對(duì)于 library 開(kāi)發(fā)者更友好一些。

同時(shí)支持的效果類(lèi)似這樣：

Tree-shaking

tree-shaking 是近兩年才在 JS 中出現(xiàn)的，之前沒(méi)有的，而模塊化的概念是一直都有方案的，只不過(guò)直到 ES Module 才有統(tǒng)一的標(biāo)準(zhǔn)趨勢(shì)。
前面提到 rollup 采用 ES Module，帶來(lái)的一個(gè)優(yōu)點(diǎn)便是 tree shaking，那什么是 tree-shaking 呢。

有一個(gè)圖片很形象的解釋了它的功能。

tree-shaking 的功能就是把我們 JS 中無(wú)用的代碼，給去掉，如果把打包工具通過(guò)入口文件，產(chǎn)生的依賴(lài)樹(shù)比作 tree，tree-shaking 就是把依賴(lài)樹(shù)中用不到的代碼 shaking 掉。

我們通過(guò)代碼了解下，webpack3.x 下打包驗(yàn)證 tree-shaking。

// 入口文件 index.js
import { func1 } from "./export1";

func1();

// export1 文件
export function func1() {
  console.log("func1");
}

export function func2() {
  console.log("func2");
}

func2 方法雖然導(dǎo)出了，但是在 index.js 中是沒(méi)有用到的，func2 就是無(wú)用代碼，最終打包生成的 build 是應(yīng)該去掉的。

使用最簡(jiǎn)單的 webpack 配置，不使用 babel，產(chǎn)出 build.js，export1 是這樣的：

/* 2 */
/***/ (function(module, __webpack_exports__, __webpack_require__) {

"use strict";
/* harmony export (immutable) */ __webpack_exports__["a"] = func1;
/* unused harmony export func2 */
function func1() {
  console.log("func1");
}

function func2() {
  console.log("func2");
}

/***/ })

我們發(fā)現(xiàn)有兩行注釋?zhuān)?b>/* harmony export (immutable) 表明代碼是有用的，unused harmony export func2表明 func2 是無(wú)用代碼，說(shuō)明 webpack 已經(jīng)識(shí)別。不過(guò) webpack 僅僅是做了“標(biāo)記”，去掉這些代碼的能力，是通過(guò)插件實(shí)現(xiàn)的，常用的便是 unglify。在 plugins 用啟用 UglifyJsPlugin 后，查看下 build。

// webpack.config.js
const UglifyJsPlugin = require("uglifyjs-webpack-plugin");
module.exports = {
  ...
 
  plugins: [
    new UglifyJsPlugin(),
  ]
}

上圖即編譯后 export1 模塊的截圖，可以看到 func2 已經(jīng)被去掉了。不過(guò)在我開(kāi)啟 babel-loader 以后，babel 配置就是一個(gè)簡(jiǎn)單的 "presets: ["env"]"，卻發(fā)現(xiàn) func2 又回來(lái)了，如下：

這是為什么呢。因?yàn)?tree-shaking 是依賴(lài) ES Module 的靜態(tài)加載，而 babel-presets-env 中是包含 ES2015 modules to CommonJS transform 的 plugin，也就是轉(zhuǎn)化成 CommonJS，所以無(wú)法識(shí)別哪些代碼是未引用的，也就是無(wú)法 tree-shaking，所以 babel transform 的時(shí)候應(yīng)該保留 ES Module。

通過(guò) presets 的 option 選擇，設(shè)置 modules 為 false 即可。

另外，tree-shaking 并不是完美無(wú)缺的，有些情況還無(wú)法識(shí)別。比如你導(dǎo)入了一個(gè)模塊，但是這個(gè)變量代碼中未使用，是不會(huì)去掉的，細(xì)節(jié)可以看這篇文章

ES Module 之前的 JS 實(shí)現(xiàn)模塊化，都是基于第三方依賴(lài)管理實(shí)現(xiàn)的，比如 requirejs，seajs，這都是在代碼執(zhí)行的時(shí)候，才知道依賴(lài)了哪些模塊，常用的 node 中的 commonjs，也是如此

(function (exports, require, module, __filename, __dirname) {
  // YOUR CODE INJECTED HERE!
});

所以，當(dāng) ES Module 在代碼不執(zhí)行的時(shí)候，就可以知道模塊的依賴(lài)關(guān)系，就不難理解是為什么了。

我的本意是，可否利用 module 字段的特性，讓我的 npm 包支持引入源碼，從而可以實(shí)現(xiàn)源碼調(diào)試、并且后編譯的效果，不過(guò)從目前的規(guī)范看來(lái)，內(nèi)部還是可以試一下的，開(kāi)源的包最好不要這樣做，除非你有自己的一套規(guī)范以及后編譯生態(tài)。雖然沒(méi)有達(dá)到目的，不過(guò)也后知后覺(jué)的了解到 module 的用意，以及 rollup 在開(kāi)發(fā)包時(shí)候的妙用，以及 tree-shaking 并不是自己了解的那么美好。

你的Tree-Shaking并沒(méi)什么卵用

【譯】如何在 Webpack 2 中使用 tree-shaking

手把手帶你走進(jìn)下一代的ES6模塊打包工具—Rollup

原文：https://github.com/configu/bl...