不可错过的Webpack核心知识点

时间  2020-12-07
标签 css 前端 node react jquery webpack git github web 正则表达式 栏目 CSS 繁體版
原文   原文链接

本文使用「署名 4.0 国际 (CC BY 4.0)」 许可协议，欢迎转载、或从新修改使用，但须要注明来源。
css

做者: 百应前端团队 @双鱼前端

https://juejin.im/user/307518985745895node

1. 核心概念

  • entry：入口。webpack是基于模块的，使用webpack首先须要指定模块解析入口(entry)，webpack从入口开始根据模块间依赖关系递归解析和处理全部资源文件。
  • output：输出。源代码通过webpack处理以后的最终产物。
  • loader：模块转换器。本质就是一个函数，在该函数中对接收到的内容进行转换，返回转换后的结果。由于 Webpack 只认识 JavaScript，因此 Loader 就成了翻译官，对其余类型的资源进行转译的预处理工做。
  • plugin：扩展插件。基于事件流框架  Tapable，插件能够扩展 Webpack 的功能，在 Webpack 运行的生命周期中会广播出许多事件，Plugin 能够监听这些事件，在合适的时机经过 Webpack 提供的 API 改变输出结果。
  • module：模块。除了js范畴内的es module、commonJs、AMD等，css @import、url(...)、图片、字体等在webpack中都被视为模块。

另外webpack4开始 mode 变成一个重要概念，webpack为不一样 mode提供了一些默认值，附上阮一峰老师的吐槽react

不一样mode的默认配置以下：jquery

2. 打包流程

  1. 初始化参数：从配置文件和 Shell 语句中读取与合并参数，得出最终的参数；
  2. 初始化编译：用上一步获得的参数初始化 Compiler 对象，注册插件并传入 Compiler 实例（挂载了众多webpack事件api供插件调用）；
  3. AST & 依赖图：从入口文件（entry）出发，调用AST引擎(acorn)生成抽象语法树AST，根据AST构建模块的全部依赖；
  4. 递归编译模块：调用全部配置的 Loader 对模块进行编译；
  5. 输出资源：根据入口和模块之间的依赖关系，组装成一个个包含多个模块的 Chunk，再把每一个 Chunk 转换成一个单独的文件加入到输出列表，这步是能够修改输出内容的最后机会；
  6. 输出完成：在肯定好输出内容后，根据配置肯定输出的路径和文件名，把文件内容写入到文件系统；

在以上过程当中，Webpack 会在特定的时间点广播出特定的事件，插件在监听到相关事件后会执行特定的逻辑，而且插件能够调用 Webpack 提供的 API 改变 Webpack 的运行结果webpack

构建流程核心概念：
  • Tapable：一个基于发布订阅的事件流工具类，Compiler 和 Compilation 对象都继承于 Tapable
  • Compiler：webpack编译贯穿始终的核心对象，在编译初始化阶段被建立的全局单例，包含完整配置信息、loaders、plugins以及各类工具方法
  • Compilation：表明一次 webpack 构建和生成编译资源的的过程，在watch模式下每一次文件变动触发的从新编译都会生成新的 Compilation 对象，包含了当前编译的模块 module, 编译生成的资源，变化的文件, 依赖的状态等

更加细化的构建流程图：git

看大图点这里👈github

流程图出处：淘系前端团队-细说 webpack 之流程篇web

3. Loader

loader就像一个翻译官，将源文件通过转换后生成目标文件并交由下一流程处理正则表达式

使用方法
  • 每一个loader职责都是单一的，就像流水线上的工人
  • 顺序很关键（从右往左）
实现准则
  • 简单【Simple】loader只作单一任务，多个loader > 一个多功能loader
  • 链式【Chaining】遵循链式调用原则
  • 无状态【Stateless】即函数式里的Pure Function，无反作用
  • 使用工具库【Loader Utilities】充分利用 loader-utils 包
实现一个简单的loader，功能是替换console.log、去除换行符、在文件结尾处增长一行自定义内容
/** webpack.config.js */  
  
const path = require("path");  
  
module.exports = {  
  entry: {  
    index: path.resolve(__dirname, "src/index.js"),  
  },  
  output: {  
    path: path.resolve(__dirname, "dist"),  
  },  
  module: {  
    rules: [  
      {  
        test: /\.js$/,  
        use: [  
          {  
            loader: path.resolve("lib/loader/loader1.js"),  
            options: {  
              message: "this is a message",  
            }  
          }  
        ],  
      },  
    ],  
  },  
};  
/** lib/loader/loader1.js */  
  
const loaderUtils = require('loader-utils');  
  
/** 过滤console.log和换行符 */  
module.exports = function (source) {  
  
  // 获取loader配置项  
  const options = loaderUtils.getOptions(this);  
  
  console.log('loader配置项:', options);  
  
  const result = source  
    .replace(/console.log\(.*\);?/g, "")  
    .replace(/\n/g, "")  
    .concat(`console.log("${options.message || '没有配置项'}");`);  
  
  return result;  
};  
  
异步loader如何编写
/** lib/loader/loader1.js */  
  
/** 异步loader */  
module.exports = function (source) {  
  
  let count = 1;  
  
  // 1.调用this.async() 告诉webpack这是一个异步loader，须要等待 asyncCallback 回调以后再进行下一个loader处理  
  // 2.this.async 返回异步回调，调用表示异步loader处理结束  
  const asyncCallback = this.async();  
  
  const timer = setInterval(() => {  
    console.log(`时间已通过去${count++}秒`);  
  }, 1000);  
  
  // 异步操做  
  setTimeout(() => {  
    clearInterval(timer);  
    asyncCallback(null, source);  
  }, 3200);  
  
};  
  
  

4. Plugin

在webpack编译整个生命周期的特定节点执行特定功能

实现要点：
  • 一个命名JS函数或者JS类
  • 在prototype上定义一个apply方法（供webpack调用，而且在调用时注入 compiler 对象）
  • 在 apply 函数中须要有经过 compiler 对象挂载的 webpack 事件钩子（钩子函数中能拿到当前编译的 compilation 对象）
  • 处理 webpack 内部实例的特定数据
  • 功能完成后调用 webpack 提供的回调
基本模型：
// 一、Plugin名称  
const MY_PLUGIN_NAME = "MyBasicPlugin";  
  
class MyBasicPlugin {  
  // 二、在构造函数中获取插件配置项  
  constructor(option) {  
    this.option = option;  
  }  
  
  // 三、在原型对象上定义一个apply函数供webpack调用  
  apply(compiler) {  
    // 四、注册webpack事件监听函数  
    compiler.hooks.emit.tapAsync(  
      MY_PLUGIN_NAME,  
      (compilation, asyncCallback) => {  
  
        // 五、操做Or改变compilation内部数据  
        console.log(compilation);        
  
        console.log("当前阶段 ======> 编译完成，即将输出到output目录");  
  
        // 六、若是是异步钩子，结束后须要执行异步回调  
        asyncCallback();  
      }  
    );  
  }  
}  
  
// 七、模块导出  
module.exports = MyBasicPlugin;  
实现一个plugin，功能是在dist目录自动生成README文件：
const MY_PLUGIN_NAME = "MyReadMePlugin";  
  
// 插件功能：自动生成README文件，标题取自插件option  
class MyReadMePlugin {  
  
  constructor(option) {  
    this.option = option || {};  
  }  
  
  apply(compiler) {  
    compiler.hooks.emit.tapAsync(  
      MY_PLUGIN_NAME,  
      (compilation, asyncCallback) => {  
        compilation.assets["README.md"] = {  
          // 文件内容  
          source: () => {  
            return `# ${this.option.title || '默认标题'}`;  
          },  
          // 文件大小  
          size: () => 30,  
        };  
        asyncCallback();  
      }  
    );  
  }  
}  
  
// 七、模块导出  
module.exports = MyReadMePlugin;  
  

compiler.hooks 上挂载了不一样时期触发的webpack事件函数（相似于React生命周期），能够在编译的各个阶段执行其余逻辑或者改变输出结果，具体支持的事件列表能够看这里：compiler-hooks

Tapable：

webpack 的插件架构主要基于 Tapable 实现的，Tapable 是 webpack 项目组的一个内部库，主要是抽象了一套插件机制。它相似于 NodeJS 的 EventEmitter 类，专一于自定义事件的触发和操做。

Tapable事件类型分为同步和异步，内部又以不一样的规则分为不一样类型，上述事件的具体区别能够看 这篇文章，理解这些事件的区别和应用场景有助于咱们理解webpack源码和编写Plugin

Complier对象：

在webpack启动时被初始化一次，全局惟一，能够理解为webpack编译实例，它包含了webpack原始配置、Loader、Plugin引用、各类钩子

部分源码：https://github.com/webpack/webpack/blob/10282ea20648b465caec6448849f24fc34e1ba3e/lib/webpack.js

5. 性能优化

1. 从何开始？

  • 使用 speed-measure-webpack-plugin 测量打包速度

  • 使用 webpack-bundle-analyzer 进行体积分析

    从某项目的分析图能够看出一个很明显的优化空间就是 BizCharts 没有按需引入，这时候咱们能够import路径再执行一次打包分析看效果。

    另外图中每一个模块都有三种Size，分别是 Stat Size、Parsed Size、Gzipped Size，这三者的分别表明什么含义能够看下插件的github issue

2. 优化Loader配置

思路主要是优化搜索时间、缩小文件搜索范围、减小没必要要的编译工做，具体作法能够看如下配置文件

module .exports = {   
  module : {   
    rules : [{  
      // 若是项目源码中只有 文件，就不要写成/\jsx?$/，以提高正则表达式的性能  
      test: /\.js$/,   
      // babel-loader 支持缓存转换出的结果，经过 cacheDirectory 选项开启  
      use: ['babel-loader?cacheDirectory'] ,   
      // 只对项目根目录下 src 目录中的文件采用 babel-loader  
      include: path.resolve(__dirname,'src'),  
      // 使用resolve.alias把原导入路径映射成一个新的导入路径，减小耗时的递归解析操做  
      alias: {  
        'react': path.resolve( __dirname ,'./node_modules/react/dist/react.min.js'),  
      },  
      // 让 Webpack 忽略对部分没采用模块化的文件的递归解析处理  
      noParse: '/jquery|lodash/',  
    }],  
  }  
}  
3. DLL Plugin Or Externals

合理使用DLLPlugin将更改频率较低的代码（三方库）移到单独的编译中，我理解大部分场景下和配置 externals 做用是差很少的（都不用打包三方库），可是 externals 在某些场景下会存在失效问题，具体能够看 这篇文章，另外 DLLPlugin 具体使用 参考这里

4. 多进程系列

多进程阵营里有几位知名选手：

  • thread-loader（v4之后的官方推荐）
  • happypack（不怎么维护了）
  • parallel-webpack（不怎么维护了）

这里只介绍一下 thread-loader ，使用 thread-loader 将开销较大的 loader（例如babel-loader）放到独立进程中（官方描述 worker pool）处理，使用上有如下注意事项

  • 将其放在须要单独加载的loader的前面，顺序很关键 
module.exports = {  
  module: {  
    rules: [  
      {  
        test: /\.js$/,  
        include: path.resolve("src"),  
        use: [  
          "thread-loader",  
          // your expensive loader (e.g babel-loader)  
        ]  
      }  
    ]  
  }  
}  
  • worker pool中的loader使用上是有限制的，例如没法使用自定义 loader api，没法获取webpack 配置项
5. 合理利用缓存 缩短非首次构建时间

目前项目在用的插件是 hard-source-webpack-plugin，效果较为显著，不过缺点有3

  1. 生成的缓存文件较大，比较占用磁盘空间（以前还出现过发布的时候误把缓存文件上传到服务器致使发布特别慢的状况 =。=，因此最好仍是指定缓存文件路径为 node_modules 内部）
  2. 这个仓库也好久没更新了
  3. 现有项目偶尔会出现更改代码不触发从新编译的状况，猜想可能与此插件有关

另外 webpack5 是否有自带的缓存策略或者官方维护的缓存插件还须要去了解一下

6. 代码压缩 减小产物体积
  • webpack3配置optimization.minimize = true会默认启用 UglifyJsPlugin，其多进程版本为 ParallelUglifyPlugin
  • webpack4 中 webpack.optimize.UglifyJsPlugin 已被废弃，默认内置使用 terser-webpack-plugin 插件压缩优化代码，原生支持多进程（这里想起官方文档 Build Performance 章节中列举的优化措施第一点：Stay Up to Date，最香的仍是最新的webpack版本）
7. Code Splitting

官方文档描述的code splitting的3种姿式：

  1. 多entry配置（多entry是自然的code splitting，可是基本没人会由于性能优化的点去把一个单页应用改为多entry）

  2. 使用 SplitChunksPlugin 进行重复数据删除和提取

  3. 使用 Dynamic Import 指定模块拆分，而且能够结合 preload、prefetch作更多用户体验上的优化

6. 想的更远：那些值得深究的问题🤔

  • HMR的原理？
  • Tree shaking原理，为何须要es module的写法？
  • webpack5的Module Federation有哪些优点，在与http2.0的结合上有哪些有趣的事情，在微前端上的应用？
  • 为何说rollup比webpack更适合打包组件库？

点个『在看』支持下 

本文分享自微信公众号 - 前端技术江湖（bigerfe）。
若有侵权，请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”，欢迎正在阅读的你也加入，一块儿分享。

相关文章
相关标签/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公众号
   欢迎关注本站公众号,获取更多信息
联系我们 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程