Webpack打包Library的原理及配置详解

Webpack Library打包原理概述

前文曾探讨Webpack打包JS模块的基础原理，案例聚焦于将多个JS模块与入口模块合并为单一bundle文件，供浏览器或JavaScript引擎直接执行，这等同于生成完整的可执行文件。然而，另一种高频场景是构建并发布JavaScript库（例如在npm社区发布个人库），此时Webpack需进行特定配置，编译生成的代码结构也会有所差异。

与前述文章一致，本文侧重于分析Webpack生成的代码，并据此阐释编译库时Webpack相关library配置选项的具体功能，对应官方文档链接见原文。

编写JS的库

编写JS库与基础配置

我们从简单案例入手，随意编写一个基础库util.js：

import $ from 'jquery'

function sayHello() {
 console.log("Hello");
}

function hideImages() {
 $('img').hide();
}

export default {
 sayHello: sayHello,
 hideImages: hideImages
}

该库提供了两个函数，二者之间无关联，且实际上并无实际用途，纯粹用于教学参考。

接下来编写Webpack的配置：

// 入口文件
entry: {
 util: './util.js',
}

// 输出文件
output: {
 path: './dist',
 filename: '[name].dist.js'
}

仅做上述配置尚不足够，这样输出的文件将是一个立即执行的函数，最终返回util.js的exports。参照前文分析，生成的bundle代码结构大致如下：

(function(modules) {
 var installedModules = {};
 
 function webpack_require(moduleId) {
   // ...
 }

 return webpack_require('./util.js');
}) ({
 './util.js': generated_util,
 '/path/to/jquery.js': generated_jquery
});

若直接执行该代码，流程即结束，仅返回util.js的export部分。但我们的目标是将此返回值赋给编译后文件的module.exports，从而使编译后的文件成为可被他人import的库。因此，期望得到的编译文件结构应如下所示：

module.exports = (function(modules) {
 var installedModules = {};
 function webpack_require(moduleId) {
   // ...
 }
 return webpack_require('./util.js');
}) ({
 './util.js': generated_util,
 '/path/to/jquery.js': generated_jquery
});

要达成上述结果，Webpack配置中的output部分需加入library信息：

// 入口文件
output: {
 path: './dist',
 filename: '[name].dist.js',

 library: 'util',
 libraryTarget: commonjs2
}

此处最关键的是libraryTarget参数。若采用commonjs2格式，即可得到前述编译结果，即Webpack会将最终输出以CommonJS形式export出来，从而实现库的发布。

LibraryTarget发布格式详解

其它发布格式

除commonjs2外，libraryTarget还支持其他选项：

var (默认值，发布为全局变量)
commonjs
commonjs2
amd
umd

使用不同选项，编译出的文件即可在不同JavaScript执行环境中运行。此处直接展示万金油umd格式的输出效果：

(function webpackUniversalModuleDefinition(root, factory) {
 if(typeof exports === 'object' && typeof module === 'object') // commonjs2
  module.exports = factory();
 else if(typeof define === 'function' && define.amd)
  define("util", [], factory); // amd
 else if(typeof exports === 'object')
  exports["util"] = factory(); // commonjs
 else
  root["util"] = factory(); // var
}) (window, function() {
 return (function(modules) {
  var installedModules = {};
  function webpack_require(moduleId) {
    // ...
  }
  return webpack_require('./util.js');
 }) ({
  './util.js': generated_util,
  '/path/to/jquery.js': generated_jquery
 });
}

相较于之前的commonjs2情况，umd格式更为复杂，因其需处理各种不同case。但后半部分逻辑一致，核心在于前几行，即umd模块的标准写法。它运行传入的factory函数（即加载模块的函数），并将返回结果根据运行环境交付给相应对象。例如，若为var，则将结果设为全局变量，用于浏览器通过<script>标签直接导入该JS文件；若为CommonJS，则交给exports对象；若为AMD环境，则采用标准AMD写法。如此，发布的JS库即可在任意环境中被他人使用。

targetExport处理ES6默认导出

targetExport控制输出内容

若使用umd格式打包，需注意一个潜在问题：若库的源代码采用ES6格式export default输出（如前述util.js示例），直接将编译后的JS库文件置于浏览器中使用（无论是<script>标签还是RequireJS），可能无法得到预期结果。这是因为你的JS文件返回的对象结构如下：

{
 'default': {
  sayHello: sayHello,
  hideImages: hideImages
 }
}

而非你所期望的：

{
 sayHello: sayHello,
 hideImages: hideImages
}

不仅浏览器环境，在不支持ES6模块系统的其他环境中也会出现此问题，原因在于它们无法识别default关键字。因此，编译后的JS文件应当仅输出default部分，这需要在Webpack配置中使用targetExport进行控制：

[[t18]]

如此，上述模块加载函数factory在返回值后会附加['default']，从而仅返回exports的default部分。

在umd格式下，这个坑相当容易踩中。例如发布一个Vue组件时，.vue文件中的JavaScript部分通常以export default格式导出Component对象，如下所示：

export default {
 name: 'xxx',
 data: {
  return // ...
 },
 props: {
  // ...
 }
 methods: {
  // ...
 }
}

若将编译后的JS文件直接置于浏览器中运行，并通过CDN方式利用<script>加载Vue，会发现Vue无法识别该Component，原因在于你得到的对象多了一层不必要的default包装。

你可能会质疑，若将输出内容改为default，是否会影响该模块在ES6环境下的使用？通常情况下不会。前文曾提及，Webpack生成代码在引入模块时，会通过__esModule值来设置和判断其是否为ES6格式的export。若仅导出default部分，该对象将被视为非ES6，因其不含__esModule。这样，其他模块通过import引入该模块时，会引入整个对象，这实际上变相等价于仅引入原模块的export default部分。

当然，以上讨论的前提是你所有需要export的内容均包含在export default中。若同时存在default和正常export，编译后的文件仅导出default部分显然不可行。

以上就是本文的全部内容，希望对大家的学习有所帮助，也希望大家多多支持本站。