这是我参与第四届青训营笔记创作活动的第十天

接上一篇，咱们先回答一下上次遗留的问题。

Q1:除上一篇提到的内容，还有哪些配置可划分为“流程类”配置?

A1:这个我实在是不知道，希望有知道的朋友可以在评论区留言！

Q2:工具类配置具体有什么作用?包括devtool/cache/stat等?

A2:其实涉及到还挺多的，那就在下面具体展开说说。

devtool

是什么

devtool其实控制是否以及如何生成源映射，它与source map绑定，选择一种 source map 风格来增强调试过程，不同的值会明显影响到构建(build)和重新构建(rebuild)的速度。

为什么

那为什么需要这个呢？

原因是开发时我们运行的代码是经过 webpack 编译后的，例如下面这个样子：

/*
 * ATTENTION: The "eval" devtool has been used (maybe by default in mode: "development").
 * This devtool is neither made for production nor for readable output files.
 * It uses "eval()" calls to create a separate source file in the browser devtools.
 * If you are trying to read the output file, select a different devtool (https://webpack.js.org/configuration/devtool/)
 * or disable the default devtool with "devtool: false".
 * If you are looking for production-ready output files, see mode: "production" (https://webpack.js.org/configuration/mode/).
 */
/******/ (() => { // webpackBootstrap
/******/         "use strict";
/******/         var __webpack_modules__ = ({/***/ "./node_modules/css-loader/dist/cjs.js!./node_modules/less-loader/dist/cjs.js!./src/less/index.less":
/*!**********************************************************************************************************!*\
  !*** ./node_modules/css-loader/dist/cjs.js!./node_modules/less-loader/dist/cjs.js!./src/less/index.less ***!
  **********************************************************************************************************/
/***/ ((module, __webpack_exports__, __webpack_require__) => {

eval("__webpack_require__.r(__webpack_exports__);\n/* harmony export */ __webpack_require__.d(__webpack_exports__, {\n/* harmony export */   "default": () => (__WEBPACK_DEFAULT_EXPORT__)\n/* harmony export */ });\n/* harmony import */ var _node_modules_css_loader_dist_runtime_noSourceMaps_js__WEBPACK_IMPORTED_MODULE_0__ = __webpack_require__(/*! ../../node_modules/css-loader/dist/runtime/noSourceMaps.js */ "./node_modules/css-loader/dist/runtime/noSourceMaps.js");\n/* harmony import */ var _node_modules_css_loader_dist_runtime_noSourceMaps_js__WEBPACK_IMPORTED_MODULE_0___default = /*#__PURE__*/__webpack_require__.n(_node_modules_css_loader_dist_runtime_noSourceMaps_js__WEBPACK_IMPORTED_MODULE_0__);\n/* harmony import */ var _node_modules_css_loader_dist_runtime_api_js__WEBPACK_IMPORTED_MODULE_1__ = __webpack_require__(/*! ../../node_modules/css-loader/dist/runtime/api.js */ "./node_modules/css-loader/dist/runtime/api.js");\n/* harmony import */ var _node_modules_css_loader_dist_runtime_api_js__WEBPACK_IMPORTED_MODULE_1___default = /*#__PURE__*/__webpack_require__.n(_node_modules_css_loader_dist_runtime_api_js__WEBPACK_IMPORTED_MODULE_1__);\n// Imports\n\n\nvar ___CSS_LOADER_EXPORT___ = _node_modules_css_loader_dist_runtime_api_js__WEBPACK_IMPORTED_MODULE_1___default()((_node_modules_css_loader_dist_runtime_noSourceMaps_js__WEBPACK_IMPORTED_MODULE_0___default()));\n// Module\n___CSS_LOADER_EXPORT___.push([module.id, ".box2 {\n  width: 100px;\n  height: 100px;\n  background-color: deeppink;\n}\n", ""]);\n// Exports\n/* harmony default export */ const __WEBPACK_DEFAULT_EXPORT__ = (___CSS_LOADER_EXPORT___);\n\n\n//# sourceURL=webpack://webpack5/./src/less/index.less?./node_modules/css-loader/dist/cjs.js!./node_modules/less-loader/dist/cjs.js");/***/ }),

这里所有 css 和 js 合并成了一个文件，并且多了其他代码。此时如果代码运行出错那么提示代码错误位置我们是看不懂的。一旦将来开发代码文件很多，那么很难去发现错误出现在哪里。所以我们需要更加准确的错误提示，来帮助我们更好的开发代码。

SourceMap

首先我们得先了解什么是SourceMap。

SourceMap（源代码映射）是一个用来生成源代码与构建后代码一一映射的文件的方案。它会生成一个 xxx.map 文件，里面包含源代码和构建后代码每一行、每一列的映射关系。当构建后代码出错了，会通过 xxx.map 文件，从构建后代码出错位置找到映射后源代码出错位置，从而让浏览器提示源代码文件出错位置，帮助我们更快的找到错误根源。

那我们应该怎么用呢？

通过查看Webpack DevTool 文档可知，SourceMap 的值有很多种情况.

但实际开发时我们只需要关注两种情况即可：

开发模式：cheap-module-source-map

优点：打包编译速度快，只包含行映射

缺点：没有列映射

     module.exports = {
     // 其他省略
         mode: "development",    
         devtool: "cheap-module-source-map",
     };

生产模式：source-map

优点：包含行/列映射

缺点：打包编译速度更慢

     module.exports = {
         // 其他省略
         mode: "production",
         devtool: "source-map",
     };

测试区别：

我们在一个js文件里面故意写错，比如下面所示，然后分别编译看情况，可以看到：

发模式下：定位到行生产模式下：定位到列

这就是SoureMap的功劳。可能有人已经想问，那我们应该怎么选择SourceMap的类型呢？

选择依据

对于开发环境，通常希望更快速的 Source Map，需要添加到 bundle 中以增加体积为代价
对于生产环境，则希望更精准（行+列，因为生产环境下代码会压缩成一行）的 Source Map，需要从 bundle 中分离并独立存在。

SourceMap的配置

其实每个配置项都只是五个关键字eval，source-map，cheap，module，inline的任意组合，每一项都代表一个特性。

SourceMap的配置有很多，这里罗列了一些比较常用的。

eval：生成代码每个模块都被eval执行，并且存在@sourceURL

cheap-eval-source-map：转换代码（行内）每个模块被eval执行，并且sourcemap作为eval的一个dataurl

cheap-module-eval-source-map：原始代码（只有行内）同样道理，但是更高的质量和更低的性能

eval-source-map：原始代码同样道理，但是最高的质量和最低的性能

cheap-source-map：转换代码（行内）生成的sourcemap没有列映射，从loaders生成的sourcemap没有被使用

cheap-module-source-map：原始代码（只有行内）与上面一样除了每行特点的从loader中进行映射

source-map：原始代码最好的sourcemap质量有完整的结果，但是会很慢

既然说到Sourcemap，那不妨再说点别的，比如：

1、sourcemap实现的不同方式？

答： eval和.map文件都是sourcemap实现的不同方式

2、什么模式决定eval或.map文件？

答：eval和source-map。

eval模式是使用eval将webpack中每个模块包裹，然后在模块末尾添加模块来源//# souceURL，依靠souceURL找到原始代码的位置。

包含source-map关键字的配置项都会产生一个.map文件，该文件保存有原始代码与运行代码的映射关系，浏览器可以通过.map找到原始代码的位置（注：包含inline关键字的配置项也会产生.map文件，但是这个map文件是经过base64编码作为DataURI嵌入，不单独生成）

注意eval-source-map是eval和source-map的组合，可知使用eavl语句包括模块，也产生了.map文件，此时webpack将.map文件作为DataURI替换eval模式中末尾的//# souceURL。

3、包含cheap关键字的配置中有什么特点？

答：如果包含cheap关键字，则产生的.map文件不包含列信息。也就是说当你在浏览器中点击该代码的位置时，光标只定位到行数，不定位到具体字符位置。而不包含cheap关键字时，点击控制台log将会定位到字符位置。

举例子：

包含列信息后点击原始代码的定位，注意光标位置：不包含列信息的光标位置：

4、这几种不同的配置有什么区别？

答：主要区别体现在重构的性能。总的来说eval性能最好（贼快），source-map性能最低，但大多用的是最完整的source-map，该模式对于不管是js还是css，scss等都能很好的覆盖，相反其他模式都不完整，在开发环境下重构性能似乎比不上功能的完善。另外需要补充的是module关键字，当加上module关键字webpack将会添加loader的sourcemap。

cache

为什么

我们为什么需要cache呢？是因为每次打包时 js 文件都要经过 Eslint 检查和 Babel 编译，速度比较慢。

所以如果我们可以缓存之前的 Eslint 检查和 Babel 编译结果，这样第二次打包时速度就会更快了。而这恰恰就是cache的功劳。

是什么

cache是局部看问题，它会对 Eslint 检查和 Babel 编译结果进行缓存。

本质

持久化缓存算得上是 Webpack 5 最令人振奋的特性之一，它能够将首次构建结果持久化到本地文件系统，在下次执行构建时跳过一系列解析、链接、编译等非常消耗性能的操作，直接复用 module、chunk 的构建结果。

怎么用

介绍了cache之后让我们来看看该怎么用？

1、开启babel-loader缓存

只需设置 cacheDirectory = true 即可开启 babel-loader 持久化缓存功能

默认情况下，babel-loader 会将缓存内容保存到 node_modules/.cache/babel-loader 目录，用户也可以通过 cacheDirectory = 'dir' 方式设置缓存路径。

2、eslint-loader 同样支持缓存功能，只需设置 cache = true 即可开启，如：

这里有一个扩展资料，感兴趣的朋友可以点进去看看

Webpack 性能之使用 Cache 提升构建性能

stat

控制webpack打包后输出哪些信息。

webpack优化

至此，一些基本的关于webpack的知识我们基本讲完了，后续我们将进行 Webpack 优化，让我们代码在编译/运行时性能更好。

我们会从以下角度来进行优化：

提升开发体验
提升打包构建速度
减少代码体积
优化代码运行性能

提升开发体验

提高开发体验的话其实是关于SourceMap的，这一篇前部分已经具体讲过就不再重复。直接进入下一个。

提升打包构建速度

HotModuleReplacement

HotModuleReplacement的话生产模式不能用，开发模式才可以。

为什么

为什么HotModuleReplacement可以提升打包构建速度呢？开发时我们修改了其中一个模块代码，Webpack 默认会将所有模块全部重新打包编译，速度很慢。所以我们需要做到修改某个模块代码，就只有这个模块代码需要重新打包编译，其他模块不变，这样打包速度就能很快。即修改一个模块代码就会全部打包编译，我们想做到改哪哪里才重新打包编译，以提高速度，做到只改有变动的！

是什么

HotModuleReplacement（HMR/热模块替换）：在程序运行中，替换、添加或删除模块，而无需重新加载整个页面。

怎么用

基本配置

module.exports = {
    // 其他省略
    devServer: {
       host: "localhost", // 启动服务器域名
       port: "3000", // 启动服务器端口号
       open: true, // 是否自动打开浏览器
       hot: true, // 开启HMR功能（只能用于开发环境，生产环境不需要了）
    },
};

此时 css 样式经过 style-loader 处理，已经具备 HMR 功能了。但是 js 还不行。

注意：hot在webpack5中默认是开启的，要测试没有hot的情况需要手动把hot的值改为false。检查hot是否起作用的方式可以是看页面是否重新加载（则浏览器左上角处）或者控制台打印的信息

Js配置

// 判断是否支持HMR功能
if (module.hot) {
  module.hot.accept("./js/count.js", function (count) {
      const result1 = count(2, 1);
      console.log(result1);
      });

  module.hot.accept("./js/sum.js", function (sum) {
      const result2 = sum(1, 2, 3, 4);
      console.log(result2);
  });
 }
//实际上这样就可以了。回调函数只是可以做其他事情
if (module.hot) {
  module.hot.accept("./js/count.js");//指定js只编译哪个文件
  module.hot.accept("./js/sum.js");
}

不过其实上面这样写会很麻烦，所以实际开发我们会使用其他 loader 来解决。

比如：vue-loader, react-hot-loader。

oneOf

为什么

为什么oneOf可以提高打包构建速度？在webpack对文件打包或者构建的时候，都会将rules里所有的规则都过一遍，如果符合，就被对应loader处理，不符合则直接过，这样会影响构建性能。即每个不同类型的文件在loader转换时，都会被命中，遍历module中rules中所有loader 所以因为单个文件只会匹配rules里的单条规则，匹配上了就没必要继续匹配，所以这里就用到了oneOf来处理这个问题。

是什么

oneOf可以提升构建速度，避免每个文件都被所有loader过一遍，因为任何一个文件，构建过程中，在遇到第一个与之对应的loader后，不会再往下进行。在oneOf里面的loader一旦匹配成功则会跳出匹配，相当于break语句

怎么用

其实也就是再loader设置时加上一个oneOf包裹起来。

module: {
  rules: [
    {
    // 包裹loader
      oneOf:[
      //loader设置
        {
          test: /.css$/,
          use: ["style-loader", "css-loader"],
        },
        {
          test: /.html$/,
          loader: "html-loader",
        },
        {
          test: /.js$/,
          loader: "eslint-loader",
        }
      ]
    }
  ],
},

扩展

1、 oneOf里面的loader只匹配一个，所以不能有两个配置处理同一种类型的文件，比如两个Loader，一个eslint，一个babel，他们都处理Js文件，那只会第一个生效，第二个不起作用。这个时候要怎么办呢？

答：对于同一类型文件，比如处理js，如果需要多个loader，可以单独抽离js处理，确保oneOf里面一个文件类型对应一个loader。 即只需要把loader放到oneOf外面即可。

例子

module: {
   rules: [
   //被单独提出来的loader
   {
      test: /.js$/,
      enforce: "pre",//那么enforce是什么呢？有什么作用呢？
      loader: "eslint-loader",
   },
   //oneOf
   {
      oneOf:[
         {
           test: /.css$/,
           use: ["style-loader", "css-loader"],
         },
         {
           test: /.html$/,
           loader: "html-loader",
         },
         {
           test: /.js$/,
           loader: "babel-loader",
         }
      ]
    }
 ],
},

2、 enforce: "pre"enforce是什么呢？有什么作用呢？

答：loader的执行顺序是从下往上的，但是有时候我们想先执行某个loader 就要把它移到最后边这样非常的不方便。enforce的作用是设置loader的优先级。 enforce有以下几个配置项:

pre 优先处理；
normal 正常处理（默认）；
inline 其次处理；
post 最后处理

执行loader的时候会根据enforce的配置来安排顺序，如果设置了pre则会优先执行

使用方法

{
   test:/.js$/,
   exclude:/node_modules/,
   loader:'eslint-loader'，
   enforce:'pre'  
}

好了，本次就先到这，下一篇我们继续聊webpack的优化。最后的最后，谢谢大家这么厉害还来看我，如果发现问题或者需要补充的点麻烦大家通过评论告诉我。博取众长，共同进步！

打包工具之Webpack篇(三) | 青训营笔记