前言
在前文中，我说过本系列文章的受众是在现代前端体系下能够熟练编写业务代码的同学，因此本文在介绍 webpack 配置时，仅提及构建一个库所特有的配置，其余配置请参考 webpack 官方文档。
输出产物
构建一个库与构建一个一般应用最大的不同点在于构建完成后输出的产物。
一般应用构建完成后会输出：
- 一个 html 文件
- 一个 js 入口 chunk 、若干子 chunk
- 若干 css 文件
- 若干其它资源，如图片、字体文件等
虽然输出的资源非常多，但实际上所有的依赖、加载关系都已经从 html 文件开始一层一层定下来了，换句话说，这个 html 文件实际上就是整个应用的入口。
一个库构建完成后会输出：
- 一个 CommonJS 格式的 js 文件
- 一个未压缩的 UMD 格式的 js 文件
- 一个已压缩的 UMD 格式的 js 文件
- 可能包括若干的 css 文件
- 可能包括若干的其它资源文件
库的入口分别是上面罗列的 js 文件；你可能会奇怪，一个库怎么会有3个入口文件呢？莫急，且听我一一道来。
CommonJS
CommonJS 是 Node.js 推行的一种模块化规范，主要语法包括module.exports、require()等；而我们在使用 webpack 引入 npm 包时，实际上是处于 Node.js 环境，由此可知，这个 CommonJS 格式的入口 js 文件（<库名称>.common.js）是供其它应用在 Node.js 环境下引入 npm 包使用的。由于在引用 npm 包时一般不会过多考虑 npm 包的体积（在构建自己的应用时如有需要可自行压缩），且为了方便调试，因此该 js 入口文件是没有经过压缩的。
UMD
UMD 是一个模块化规范大杂烩，除了兼容 CommonJS 外，它还兼容 AMD 模块化规范，以及最传统的全局变量模式。
这边稍微介绍一下 AMD 规范， AMD 全称 Asyncchronous Module Definition ，一般应用在浏览器端（这是与 CommonJS规范最大的不同点），最著名的 AMD 加载器是 RequireJS 。目前由于 webpack 的流行， AMD 这一模块化方案已逐渐退出市场。
全局变量模式就很好理解了，就是把库的入口挂载在一个全局变量（如window.xxx）上，页面上的任何位置都能随时取用，属于最传统的 js 插件加载方案。
由上可知， UMD 格式的入口 js 文件，既可以用于引用 npm 包的场景（未压缩的版本，即<库名称>.umd.js），也可以直接用于浏览器端（已压缩的版本，即<库名称>.umd.min.js）。
如何构建不同模块化规范的库文件
目前， webpack 不支持同时生成多份入口 js 文件，因此需要分多次来进行构建。
关键的 webpack 配置是：
- CommonJS：
output.libraryTarget: "commonjs2" - UMD：
output.libraryTarget: "umd"
对于 UMD ，我们还需要设置全局变量名称，即output.library: "LibraryName"。
为了压缩构建出来的文件，最简单的方法是在 CLI 中调用 webpack 命令时带上 mode 参数，如webpack --mode=production；这是因为当 mode 的值为production时， webpack 会自动启用 UglifyJsPlugin 对源码进行压缩。
输出版本信息
我在某公司工作时，该公司对第三方依赖抓得很紧，所有在项目里使用的第三方依赖都必须申请且审核通过后才可使用；且申请时是精确到具体版本的，未申请的软件版本也一概不允许使用。某些第三方依赖无论在文件内容上，还是在文件名称上，都没有体现出版本号，这就对我们识别这类第三方依赖产生障碍，这是我们开发自己的库时需要引以为戒的。
在构建库时，我们完全可以利用 webpack 把库的信息直接输出到文件内容里，有了这“身份信息”，用户使用起来也会格外安心。
输出库版本信息的方法是使用 webpack.BannerPlugin ，最简单的使用方法如下：
const pgk = require('./package.json');
const banner = `
${pkg.name}
${pkg.description}\n
@version v${pkg.version}
@homepage ${pkg.homepage}
@repository ${pkg.repository.url}\n
(c) 2019 Array-Huang
Released under the MIT License.
hash: [hash]
`;
/* webpack 配置 */
{
// ...其它配置
plugins: [
// ...其它 plugin 配置
new webpack.BannerPlugin(banner);
]
}
最终生成出来的效果是：
/*!
*
* vue-directive-window
* Vue.js directive that enhance your Modal Window, support drag, resize and maximize.
*
* @version v0.7.5
* @homepage https://github.com/Array-Huang/vue-directive-window
* @repository git+https://github.com/Array-Huang/vue-directive-window.git
*
* (c) 2019 Array-Huang
* Released under the MIT License.
* hash: dc6c11a1e50821f4444a
*
*/
source map
如果库的用户是直接通过在浏览器里加载你的库来使用的话，那么提供一份 source map 文件是非常有必要的；这是因为你的库在经过 webpack 构建，甚至压缩后，与源代码已经大相径庭了，用户将难以在浏览器中进行调试；但如果你能为自己的库附上一份 source map ，浏览器开发者工具会调用 source map 来帮助解析，用户的调试体验会更接近于调试库的源码。
相应的 webpack 配置为：
// webpack 配置
{
// ...其它配置
devtool: 'cheap-module-source-map'
}
webpack 支持多种类型的 source map ，不同类型的 source map 在生成速度、支持功能（如 babel ）、调试位置偏移等问题上均有不同表现，我这边只做推荐：
- 开发环境：cheap-module-eval-source-map
- 生产环境：cheap-module-source-map
关于其它类型的 source map ，请查看 webpack 官方文档的 devtool 章节。
排除第三方依赖
与一般应用不一样，在开发库的时候，我们应尽量避免引入第三方库（构建过程中使用的工具链除外），因为这些第三方库会让我们写的库的大小猛增；很可能会出现这样的情况：我们自己写的小功能只有几百行代码的逻辑，构建出来的库却有几百k，那这样的库意义就不大了。
但我们的确也很难避免使用第三方库，那该咋办呢？
// webpack 配置
{
// ...其它配置
externals: {
lodash: {
commonjs: 'lodash',
commonjs2: 'lodash',
amd: 'lodash',
root: '_'
}
}
}
使用上述配置后，我们构建出来的库中就不会包含配置中指定的第三方库（例子中为lodash）了，下面来一一详解：
-
commonjs和commonjs2项都是指明用户在 node.js 环境下使用当前库时，以 CommonJS 的方式来加载名为lodash的 npm 包。 -
amd项表示在浏览器中加载运行本库时，本库会试图以 AMD 的方式来加载名为lodash的 AMD 模块。 -
root项表示在浏览器中加载运行本库时，本库会试图取全局变量window._（通过