刚刚，发布Webpack中级教程系列

曾经终败给现在 2022-09-04 10:40 150阅读 0赞

![2e29ea9df259c1aa5a317c3eeaeee050.png][]

webpack是什么？

`webpack`是前端最火的打包工具，是大前端自动化工厂的重要组成部分。

webpack关于HTML的部分

\- 对于浏览器而言，`html`文件是用户访问的入口点，也是所有资源的挂载点，所有资源都是通过`html`中的标记来进行引用的。

\- 在`webpack`的构建世界里，`html`只是一个展示板，而`entry`参数中指定的`javascript`入口文件才是真正在构建过程中管理和调度资源的挂载点，`html`文件中最终展示的内容，都是`webpack`在加工并为所有资源打好标记以后传递给它的，业界将这种有别与浏览器的模式称之为**“webpack的逆向注入”**

\- 前端项目可以大致分为 **单页面应用** 和 **多页面应用**

\- `html`文件主要作为访问入口文件，是`<style>` 样式标签和`<script>`脚本标签的挂载点

打包中需要注意：

\- 第一，个性化内容填充，如页面标题，描述，关键字；

\- 第二，多余空格删除，连续多个空白字符的合并；

\- 第三，代码压缩，多余空白字符的合并；

\- 第四，去除注解

入口html文件的处理

\- 单页面应用打包

入口html文件的处理使用 html-webpack-plugin 插件来设置一定的配置参数。

webpack.config.js配置

![9fed55b44eee1ef44705eadc9c5ab717.png][]

index.html 模板文件（构建生成的入口页面是以此为模板的）：

![86f379bdf2cd8cadd12dd0c77ee181ac.png][]

多页面应用打包

项目中有多个页面，考虑两个基本问题：

\- 如何自动生成多个页面

\- 如果引用中存在公共的模块，怎么样才能提取公共模块

> 多页面应用的基本结构理解起来并不复杂，可以将其看做是多个单页面应用的组合

\- entry参数需要配置多个依赖入口文件

![7ded5e58f6b8cd5f8e99296c32956af8.png][]

html文件则需要分别引用对应的入口文件并生成对应的访问入口：

![7cf2fc0b079d36d7d871180f61bdb84b.png][]

可以看到在生成`html`文件时已经为其单独引用了`chunks`数组中指定的模块，这使得对应的页面生成时只依赖自己需要的脚本。

`html-webpack-plugin`插件是依赖于`html-loader`而工作的，当你显式使用`/\.html$/`作为规则来筛选文件时，同样会选择到作为入口文件的`html`资源，从而造成冲突报错。

webpack中关于CSS的部分

CSS文件的处理，需要处理的基本问题：

\- 预编译语言转换

\- 样式文件挂载方式选择

\- 代码优化（合并以及压缩）

\- 去除或保留指定格式的注解

\- 资源定位路径的转换

\- 响应式布局单位转换

\- 模块化

\- 处理浏览器兼容

> 解决方案

\- **旧的解决方案**：`预编译语言` + `命名方法论`

\- **新的解决方案**：`预编译语言` + `构建工具` + `BEM + ACSS全局样式`\+`CSSModule组件样式`\+ `POSTCSS`

旧：例如编写简单的`@mixin px2rem( )`函数来将开发中使用的px单位转换为rem单位，达到移动端自适应的目的，或是编写一些处理兼容性的函数来处理浏览器兼容性。

新：**构建工具**可以通过自动化检测将预编译语言转换为`CSS`，基于现代化构建工具的`CSS-Module`功能，可以通过特定的语法解决**CSS模块化**的问题，而基于`POSTCSS`实现的`autoprefixer`插件，可以依据CanIUse网站提供的浏览器支持度数据实现代码的跨浏览器前缀自动补齐。

常用的插件：

\- style-loader——将处理结束的CSS代码存储在js中，运行时嵌入<style>后挂载至html页面上

\- css-loader——加载器，使webpack可以识别css模块

\- postcss-loader——加载器

\- sass-loader——加载器，使webpack可以识别scss/sass文件，默认使用node-sass进行编译

\- mini-css-extract-plugin——插件，4.0版本启用的插件，替代原extract-text-webpack-plugin插件，将处理后的CSS代码提取为独立的CSS文件

\- optimize-css-assets-webpack-plugin——插件，实现CSS代码压缩

\- autoprefixer——自动化添加跨浏览器兼容前缀

使用`SCSS`作为预编译语言

![c19db84289fb7a3a2cfefbb1a0ba1f66.png][]

![fa26fb28aa83e6d6c7328c03736dd1f0.png][]

![d5241768da3ccd76d6506f397270fb69.png][]

可以看到转换后的结果:

![78a1e590cf7d4c65f503e4e80f2a0e59.png][]

代码压缩等优化功能在 默认当mode: 'production'时有效

使用CSS-Modules

**CSS Module**在CSS中使用类选择器，其基本原理是将CSS代码中的样式名替换为哈希值，并建立一个`json`对照表，在`js`文件中对于属性名选择器的使用均被替换为哈希字符串，以此来解决CSS模块化的问题。

在webpack中使用`CSS Modules`功能非常简单，只需要在`css-loader`的配置参数中设置:\{modules:true\}即可激活模块化功能。

开启模块化功能后再进行打包，可以看到同样的`main.css`文件变成了如下样子：

![bec0bafd0d48df75bdea0b7abf136441.png][]

进一步了解 Css-Process-Chain

webpack中关于Assets部分

## Assets资源的基本处理需求 ##

`Assets`，指项目中被引用的资源，通常为各种格式的图片和字体文件，当然也可能包含各式各样其他扩展名的文件（`.json`,`.xml`等），常见的图片和文字资源的处理包括：

\- 体积压缩

\- 雪碧图合并及引用修正

\- 资源的引用路径自动替换

## webpack处理引用资源 ##

### 资源打标 ###

`webpack`通过`file-loader`处理资源文件，它会将`rules`规则命中的资源文件按照配置的信息（路径，名称等）输出到指定目录，并返回其资源定位地址（输出路径，用于生产环境的`publicPath`路径），默认的输出名是以原文件内容计算的MD5 Hash命名的。

![e54cc9c1da7fc721b0f219af6b524384.png][]

### 引用优化 ###

构建工具通过`url-loader`来优化项目中对于资源的引用路径，并设定大小限制，当资源的体积小于`limit`时将其直接进行**Base64转换**后嵌入引用文件，体积大于`limit`时可通过fallback参数指定的`loader`进行处理。

![e782706da441daa80baa251ad7eaf177.png][]

### sprites雪碧图合成 ###

雪碧图合成，听起来是一个显得略高端的知识点，但它并不是必须进行的，任何一种技术都有其使用场景。有的场景下需要将图片资源合并为独立的雪碧图而减少http请求的次数，有的时候或许通过`url-loader`直接将其嵌入文档就可以。矢量图在不同场景下的处理方式也不相同。

采用`url-loader + file-loader`作为资源处理的一般通用方案

位图处理

![1a3229eec7d0db94d57f6fa9cc15e492.png][]

![dea3ce0a0b60c80464fd98a67ae3ea17.png][]

矢量图处理

开发中常用的矢量图为`svg`格式，既可以使用`inline-svg-loader`进行资源嵌入，也可以使用`svg-sprite-loader`将矢量图资源合并为雪碧图，具体采用哪种方案，需要由项目的实际情况来判断。

![519168a460fe341969e1e77298fe0070.png][]

### 图片压缩 ###

\- 图片资源是可以以清晰度为量化参考进行体积压缩的‍

webpack中关于JavaScript和splitChunk

`javascript`之所以需要打包合并，是因为模块化开发的存在。开发阶段我们需要将`js`文件分开写在很多零碎的文件中，方便调试和修改，但如果就这样上线，那首页的`http`请求数量将直接爆炸。同一个项目，别人2-3个请求就拿到了需要的文件，而你的可能需要20-30个，结果就不用多说了。

但是合并脚本可不是“把所有的碎片文件都拷贝到一个`js`文件里”这样就能解决的，不仅要解决命名空间冲突的问题，还需要兼容不同的模块化方案，更别提根据模块之间复杂的依赖关系来手动确定模块的加载顺序了，所以利用自动化工具来将开发阶段的`js`脚本碎片进行合并和优化是非常有必要的。

JS文件的打包：

\- 代码编译（TS或ES6代码的编译）

\- 脚本合并

\- 公共模块识别

\- 代码分割

\- 代码压缩混淆

## 使用webpack处理js文件 ##

### 使用babel转换ES6+语法 ###

`babel`是`ES6`语法的转换工具

![fa33808b0798f584cb5b4758ff1fc0a9.png][]

### 脚本合并 ###

\- **模块管理**和**文件合并**这两个功能是`webpack`最初设计的主要用途

\- `webpack`默认支持的是`CommonJs`规范

### 公共模块识别 ###

![889ea803dfd72856707060e3f169813c.png][]

### 代码分割 ###

![f1ddd05b4affd6a276bf4586c9ff6025.png][]

**为什么要进行代码分割？**

代码分割最基本的任务是分离出第三方依赖库，因为第三方库的内容可能很久都不会变动，所以用来标记变化的摘要哈希`contentHash`也很久不变，这也就意味着我们可以利用本地缓存来避免没有必要的重复打包，并利用浏览器缓存避免冗余的客户端加载。另外当项目发布新版本时，如果第三方依赖的`contentHash`没有变化，就可以使用客户端原来的缓存文件（通用的做法一般是给静态资源请求设置一个很大的`max-age`），提升访问速度。另外一些场景中，代码分割也可以提供对脚本在整个加载周期内的加载时机的控制能力。

**代码分割的使用场景**

举个很常见的例子，比如你在做一个数据可视化类型的网站，引用到了百度的`Echarts`作为第三方库来渲染图表，如果你将自己的代码和`Echarts`打包在一起生成一个`main.bundle.js`文件，这样的结果就是在一个网速欠佳的环境下打开你的网站时，用户可能需要面对很长时间的白屏，你很快就会想到将`Echarts`从主文件中剥离出来，让体积较小的主文件先在界面上渲染出一些动画或是提示信息，然后再去加载`Echarts`，而分离出的`Echarts`也可以从速度更快的`CDN`节点获取，如果加载某个体积庞大的库，你也可以选择使用懒加载的方案，将脚本的下载时机延迟到用户真正使用对应的功能之前。这就是一种人工的代码分割。

从上面的例子整个的生命周期来看，我们将原本一次就可以加载完的脚本拆分为了两次，这无疑会加重服务端的性能开销，毕竟建立TCP连接是一种开销很大的操作，但这样做却可以换来**对渲染节奏的控制和用户体验的提升**，**异步模块**和**懒加载模块**从宏观上来讲实际上都属于**代码分割**的范畴。`code splitting`最极端的状况其实就是拆分成打包前的原貌，也就是**源码直接上线**。

**代码分割的本质**

**源代码直接上线**

代码分割：优点是过程可控，可减少首屏空白时长；缺点是http请求多，性能开销大。

Code Splitting与平衡（请求可合并的脚本；某较大的第三方库；工具型第三方库；某个按钮点击后加载。

客户端-》缓存命中率高-》性能开销和用户体验的平衡

打包为一个脚本上线（main.bundle.js）

优点：一把搞完，省事，服务器压力小；缺点：时间长，页面空白期长

### 代码混淆压缩 ###

\- `webpack4`中已经内置了`UglifyJs`插件，当打包模式参数`mode`设置为`production`时就会自动开启

\- `babel`的插件中也能提供代码压缩的处理

## splitChunks技术 ##

![a3642bf5f678d45ee7cb7f70210dfb92.png][]

### 参数配置 ###

![832d5f3c0a1dc54ed03174d41bc3d77a.png][]

### 代码分割实例 ###

单页面应用

单页面应用只有一个入口文件，`splitChunks`的主要作用是将引用的第三方库拆分出来。从下面的分包结果就可以看出，`node_modules`中的第三方引用被分离了出来，放在了`vendors-main.[hash].js`中。

webpack --config webpack.spa.config.js

多页面应用

源码的依赖关系为：

entryA.js: vue vuex component10k
    entryB.js: vue axios component10k
    entryC.js: vue vuex axios component10k

![7c85842eb3f99ceb5750a40f77cc6f6f.png][]

`splitChunks`提供了更精确的分割策略，但是似乎无法直接通过`html-webpack-plugin`配置参数来动态解决分割后代码的注入问题，因为分包名称是不确定的。这个场景在使用`chunks:'async'`默认配置时是不存在的，因为异步模块的引用代码是不需要以`<script>`标签的形式注入`html`文件的。

当`chunks`配置项设置为`all`或`initial`时，就会有问题，例如上面示例中，通过在`html-webpack-plugin`中配置`excludeChunks`可以去除page和about这两个chunk，但是却无法提前排除vendors-about-page这个chunk，因为打包前无法知道是否会生成这样一个chunk。

webpack中的关于Module

大前端模块化

CMD规范：引用Sea.js；浏览器

Webpack可识别：

UMD规范：AMD规范（引用Require.js）；浏览器

CommonJs规范：原生支持，node

ESHarmony规范：支持度暂不完善，统一JS全环境

\- **脚本合并**是基于模块化规范的

## webpack与模块化 ##

`webpack`默认支持的是`CommonJs`规范，毕竟它是`nodejs`支持的模块管理方式，而没有`node`哪来的`webpack`。但同时为了扩展其使用场景，`webpack`在版本迭代中也加入了对`ES harmony`规范和`AMD`规范的兼容。

### webpack如何识别CommonJs模块 ###

![56bc59b1ece9eafd1c9d7b4a8455d40f.png][]

### webpack如何识别ES Harmony模块 ###

![7f9088712750178e7a1e1dde1078cc4c.png][]

![1c370077342b6e52e128c864746e2612.png][]

![b952b9be8d3381262dbf1f8e2946fe5c.png][]

webpack是一个JS代码模块化的打包工具。

资料官网：www.webpackjs.com

[2e29ea9df259c1aa5a317c3eeaeee050.png]: /images/20220829/fecd236f1886497d9839fe9b8341edc7.png
[9fed55b44eee1ef44705eadc9c5ab717.png]: /images/20220829/7778494acf904773a0a728482cf37616.png
[86f379bdf2cd8cadd12dd0c77ee181ac.png]: /images/20220829/5f7654b3930845b495beab9c6ab03f51.png
[7ded5e58f6b8cd5f8e99296c32956af8.png]: /images/20220829/84527b44fa2447dc9322035b96207e9d.png
[7cf2fc0b079d36d7d871180f61bdb84b.png]: /images/20220829/6bb1e459c48544da94caab17dc6e19d3.png
[c19db84289fb7a3a2cfefbb1a0ba1f66.png]: /images/20220829/02429777206544779afdab9b89f8ead2.png
[fa26fb28aa83e6d6c7328c03736dd1f0.png]: /images/20220829/39af0ea0abe74038ba58c2bab27abf96.png
[d5241768da3ccd76d6506f397270fb69.png]: /images/20220829/97ea3d77c9bc476d93294ba514737dbd.png
[78a1e590cf7d4c65f503e4e80f2a0e59.png]: /images/20220829/26396d64418c42c1bb082f3a0fc5ab02.png
[bec0bafd0d48df75bdea0b7abf136441.png]: /images/20220829/1c798f6d1e304aa3bb7543c9b483461e.png
[e54cc9c1da7fc721b0f219af6b524384.png]: /images/20220829/e8749a2d21484616b2602e8e5059bd0b.png
[e782706da441daa80baa251ad7eaf177.png]: /images/20220829/ee1e09868b01405386841d8221b4f122.png
[1a3229eec7d0db94d57f6fa9cc15e492.png]: /images/20220829/b0f7b53faa5f4b3ca1f8576a7f1a1554.png
[dea3ce0a0b60c80464fd98a67ae3ea17.png]: /images/20220829/7e6a157f389049abb2ffd050454255fa.png
[519168a460fe341969e1e77298fe0070.png]: /images/20220829/975f2c44807d4ef0a3880cb50630236e.png
[fa33808b0798f584cb5b4758ff1fc0a9.png]: /images/20220829/29e0769b1cfa4a209a6599a883e96a5c.png
[889ea803dfd72856707060e3f169813c.png]: /images/20220829/256b93ad53784f12a95b32941875c9b7.png
[f1ddd05b4affd6a276bf4586c9ff6025.png]: /images/20220829/d7420d845b5a4f119c63a3c1f90c1c21.png
[a3642bf5f678d45ee7cb7f70210dfb92.png]: /images/20220829/4f3357051bd147b396befa0e0b07842f.png
[832d5f3c0a1dc54ed03174d41bc3d77a.png]: /images/20220829/dbbb77144cb545999d1e825be116c4ee.png
[7c85842eb3f99ceb5750a40f77cc6f6f.png]: /images/20220829/04100ba49b1d4ff1b12254544a2f008a.png
[56bc59b1ece9eafd1c9d7b4a8455d40f.png]: /images/20220829/88ac11a2dbed477587a9048bd287eae5.png
[7f9088712750178e7a1e1dde1078cc4c.png]: /images/20220829/a29f9d6f99c2448d9bbc7242f92073fd.png
[1c370077342b6e52e128c864746e2612.png]: /images/20220829/d8b75ec7b8954e028af25ea6ce0f0c7f.png
[b952b9be8d3381262dbf1f8e2946fe5c.png]: /images/20220829/644f27179f014088b542479447cbf899.png