Webpack构建优化：缩小文件搜索范围的五大配置策略

Webpack 构建原理与性能瓶颈

Webpack 启动后，会从配置的 Entry 入口开始，解析文件中的导入语句，并进行递归解析。

当遇到导入语句时，Webpack 主要执行两项操作：

1. 根据导入语句定位并寻找对应的目标文件。例如，require('react') 指向 ./node_modules/react/react.js，而 require('./util') 指向 ./util.js。

2. 根据找到的目标文件后缀，调用配置中对应的 Loader 对文件进行处理。例如，使用 ES6 编写的 JavaScript 文件需通过 babel-loader 进行转换。

处理单个文件时，上述两步操作速度较快，但随着项目规模扩大，文件数量激增，构建速度慢的问题便会凸显。

虽然上述两步操作无法避免，但可以通过减少其发生频率来提升构建速度。

接下来将逐一介绍优化这些步骤的具体方法。

优化 Loader 配置

优化 Loader 配置

由于 Loader 的文件转换操作耗时较长，应尽量减少被 Loader 处理的文件数量。

在 2-3 Module 章节中曾介绍，使用 Loader 时可通过 test、include、exclude 三个配置项来限定应用规则的文件范围。

为了最小化 Loader 的处理范围，建议通过 include 配置明确指定需要处理的文件。

以采用 ES6 的项目为例，在配置 babel-loader 时，可参考以下配置：

module.exports = {
 module: {
  rules: [
   {
    // 如果项目源码中只有 js 文件就不要写成 /\.jsx?$/，提升正则表达式性能
    test: /\.js$/,
    // babel-loader 支持缓存转换出的结果，通过 cacheDirectory 选项开启
    use: ['babel-loader?cacheDirectory'],
    // 只对项目根目录下的 src 目录中的文件采用 babel-loader
    include: path.resolve(__dirname, 'src'),
   },
  ]
 },
};

你可以适当调整项目目录结构，以便在配置 Loader 时通过 include 进一步缩小命中范围。

优化 resolve.modules 配置

优化 resolve.modules 配置

在 2-4 Resolve 章节中曾介绍，resolve.modules 用于配置 Webpack 搜索第三方模块的目录。

resolve.modules 的默认值为 ['node_modules'] ，其含义是先在当前目录下的 ./node_modules 中查找模块，若未找到则向上层目录 ../node_modules 查找，依此类推，这与 Node.js 的模块查找机制相似。

当所有第三方模块均存放在项目根目录下的 ./node_modules 中时，无需按默认方式层层查找，可指定存放第三方模块的绝对路径以减少搜索步骤，配置如下：

module.exports = {
 resolve: {
  // 使用绝对路径指明第三方模块存放的位置，以减少搜索步骤
  // 其中 __dirname 表示当前工作目录，也就是项目根目录
  modules: [path.resolve(__dirname, 'node_modules')]
 },
};

优化 resolve.mainFields 配置

优化 resolve.mainFields 配置

在 2-4 Resolve 章节中曾介绍，resolve.mainFields 用于配置第三方模块使用哪个入口文件。

安装的第三方模块通常包含 package.json 文件，用于描述模块属性，其中某些字段指定了入口文件的位置，resolve.mainFields 用于配置采用哪个字段作为入口文件的描述。

存在多个字段描述入口文件的原因在于，某些模块可同时适用于多种环境，针对不同运行环境需使用不同的代码。

以 isomorphic-fetch 为例，它是 fetch API 的一种实现，但可同时用于浏览器和 Node.js 环境。

它的 package.json 中包含两个入口文件描述字段：

{
 "browser": "fetch-npm-browserify.js",
 "main": "fetch-npm-node.js"
}

isomorphic-fetch 在不同运行环境下使用不同代码，是因为 fetch API 的实现机制不同：在浏览器中通过原生 fetch 或 XMLHttpRequest 实现，在 Node.js 中通过 http 模块实现。

resolve.mainFields 的默认值与当前的 target 配置相关，对应关系如下：

• 当 target 为 web 或者 webworker 时，值为 ["browser", "module", "main"]
• 当 target 为其它情况时，值为 ["module", "main"]

以 target 等于 web 为例，Webpack 会先采用第三方模块中的 browser 字段查找入口文件，若不存在则采用 module 字段，依此类推。

为了减少搜索步骤，在明确第三方模块的入口文件描述字段时，可将其设置得尽可能少。

由于大多数第三方模块采用 main 字段描述入口文件位置，可这样配置 Webpack：

module.exports = {
 resolve: {
  // 只采用 main 字段作为入口文件描述字段，以减少搜索步骤
  mainFields: ['main'],
 },
};

使用此方法优化时，需考虑所有运行时依赖的第三方模块的入口文件描述字段，若有一个模块配置错误，可能导致构建出的代码无法正常运行。

优化 resolve.alias 配置

优化 resolve.alias 配置

在 2-4 Resolve 章节中曾介绍，resolve.alias 配置项通过别名将原导入路径映射为新的导入路径。

在实战项目中，常依赖一些庞大的第三方模块，以 React 库为例，安装到 node_modules 目录下的 React 库目录结构如下：

├── dist │ ├── react.js │ └── react.min.js ├── lib │ ... 还有几十个文件被忽略 │ ├── LinkedStateMixin.js │ ├── createClass.js │ └── React.js ├── package.json └── react.js

可以看到发布出去的 React 库中包含两套代码：

• 一套是采用 CommonJS 规范的模块化代码，这些文件都放在 lib 目录下，以 package.json 中指定的入口文件 react.js 为模块的入口。
• 一套是把 React 所有相关的代码打包好的完整代码放到一个单独的文件中，这些代码没有采用模块化可以直接执行。其中 dist/react.js 是用于开发环境，里面包含检查和警告的代码。 dist/react.min.js 是用于线上环境，被最小化了。

默认情况下 Webpack 会从入口文件 ./node_modules/react/react.js 开始递归的解析和处理依赖的几十个文件，这会时一个耗时的操作。

通过配置 resolve.alias 可以让 Webpack 在处理 React 库时，直接使用单独完整的 react.min.js 文件，从而跳过耗时的递归解析操作。

相关 Webpack 配置如下：

module.exports = {
 resolve: {
  // 使用 alias 把导入 react 的语句换成直接使用单独完整的 react.min.js 文件，
  // 减少耗时的递归解析操作
  alias: {
   'react': path.resolve(__dirname, './node_modules/react/dist/react.min.js'),
  }
 },
};

除了 React 库外，大多数库发布到 Npm 仓库中时都会包含打包好的完整文件，对于这些库你也可以对它们配置 alias。 但是对于有些库使用本优化方法后会影响到后面要讲的 使用 Tree-Shaking 去除无效代码 的优化，因为打包好的完整文件中有部分代码你的项目可能永远用不上。

一般对整体性比较强的库采用本方法优化，因为完整文件中的代码是一个整体，每一行都是不可或缺的。

但是对于一些工具类的库，例如 lodash ，你的项目可能只用到了其中几个工具函数，你就不能使用本方法去优化，因为这会导致你的输出代码中包含很多永远不会执行的代码。

优化 resolve.extensions 配置

优化 resolve.extensions 配置

在导入语句没带文件后缀时，Webpack 会自动带上后缀后去尝试询问文件是否存在。

在 2-4 Resolve 中介绍过 resolve.extensions 用于配置在尝试过程中用到的后缀列表，默认是：

extensions: ['.js', '.json']

也就是说当遇到 require('./data') 这样的导入语句时，Webpack 会先去寻找 ./data.js 文件，如果该文件不存在就去寻找 ./data.json 文件，如果还是找不到就报错。

如果这个列表越长，或者正确的后缀在越后面，就会造成尝试的次数越多，所以 resolve.extensions 的配置也会影响到构建的性能。

在配置 resolve.extensions 时你需要遵守以下几点，以做到尽可能的优化构建性能：

• 后缀尝试列表要尽可能的小，不要把项目中不可能存在的情况写到后缀尝试列表中。
• 频率出现最高的文件后缀要优先放在最前面，以做到尽快的退出寻找过程。
• 在源码中写导入语句时，要尽可能的带上后缀，从而可以避免寻找过程。例如在你确定的情况下把 require('./data') 写成 require('./data.json') 。

相关 Webpack 配置如下：

module.exports = {
 resolve: {
  // 尽可能的减少后缀尝试的可能性
  extensions: ['js'],
 },
};

优化 module.noParse 配置

优化 module.noParse 配置

在 2-3 Module 中介绍过 module.noParse 配置项可以让 Webpack 忽略对部分没采用模块化的文件的递归解析处理，这样做的好处是能提高构建性能。

原因是一些库，例如 jQuery 、ChartJS， 它们庞大又没有采用模块化标准，让 Webpack 去解析这些文件耗时又没有意义。

在上面的 优化 resolve.alias 配置 中讲到单独完整的 react.min.js 文件就没有采用模块化，让我们来通过配置 module.noParse 忽略对 react.min.js 文件的递归解析处理，

相关 Webpack 配置如下：

const path = require('path');
module.exports = {
 module: {
  // 独完整的 `react.min.js` 文件就没有采用模块化，忽略对 `react.min.js` 文件的递归解析处理
  noParse: [/react\.min\.js$/],
 },
};

注意被忽略掉的文件里不应该包含 import 、 require 、 define 等模块化语句，不然会导致构建出的代码中包含无法在浏览器环境下执行的模块化语句。

总结

以上所述是小编给大家介绍的Webpack优化配置缩小文件搜索范围，希望对大家有所帮助，如果大家有任何疑问请给我留言，小编会及时回复大家的。在此也非常感谢大家对本站网站的支持！