g841805的博客

2.提升 webpack 提升打包构建速度。4.优化代码运行性能。

打包代码时会将所有 js 文件打包到一个文件中，体积太大了。我们如果只要渲染首页，就应该只加载首页的 js 文件，其他文件不应该加载。所以我们需要将打包生成的文件进行代码分割，生成多个 js 文件，渲染哪个页面就只加载某个 js 文件，这样加载的资源就少，速度就更快。

开发时我们定义了一些工具函数库，或者引用第三方工具函数库或组件库。如果没有特殊处理的话我们打包时会引入整个库，但是实际上可能我们可能只用上极小部分的功能。这样将整个库都打包进来，体积就太大了。

开发时我们修改了其中一个模块代码，Webpack 默认会将所有模块全部重新打包编译，速度很慢。所以我们需要做到修改某个模块代码，就只有这个模块代码需要重新打包编译，其他模块不变，这样打包速度就能很快。

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

通过前面的内容我们学会了 Webpack 基本使用，掌握了以下功能：

默认生产模式已经开启了：html 压缩和 js 压缩。

Css 文件目前被打包到 js 文件中，当 js 文件加载时，会创建一个 style 标签来生成样式这样对于网站来说，会出现闪屏现象，用户体验不好我们应该是单独的 Css 文件，通过 link 标签加载性能才好。

生产模式是开发完成代码后，我们需要得到代码将来部署上线。这个模式下我们主要对代码进行优化，让其运行性能更好。

每次写完代码都需要手动输入指令才能编译代码，太麻烦了，我们希望一切自动化。

去掉引入的 js 文件，因为 HtmlWebpackPlugin 会自动引入。此时 dist 目录就会输出一个 index.html 文件。

有人可能会问，js 资源 Webpack 不能已经处理了吗，为什么我们还要处理呢？原因是 Webpack 对 js 处理是有限的，只能编译 js 中 ES 模块化语法，不能编译其他语法，导致 js 不能在 IE 等浏览器运行，所以我们希望做一些兼容性处理。其次开发中，团队对代码格式是有严格要求的，我们不能由肉眼去检测代码格式，需要使用专业的工具来检测。我们先完成 Eslint，检测代码格式无误后，在由 Babel 做代码兼容性处理。

开发中可能还存在一些其他资源，如音视频等，我们也一起处理了。

打开 index.html 页面查看效果。

观察 dist 目录资源情况。

（注意：需要将上次打包生成的文件清空，再重新打包才有效果）

过去在 Webpack4 时，我们处理图片资源通过 file-loader 和 url-loader 进行处理现在 Webpack5 已经将两个 Loader 功能内置到 Webpack 里了，我们只需要简单配置即可处理图片资源。

Webpack 本身是不能识别样式资源的，所以我们需要借助 Loader 来帮助 Webpack 解析样式资源我们找 Loader 都应该去官方文档中找到对应的 Loader，然后使用官方文档找不到的话，可以从社区 Github 中搜索查询Webpack 官方 Loader 文档css-loader：负责将 Css 文件编译成 Webpack 能识别的模块style-loader：会动态创建一个 Style 标签，里面放置 Webpack 中 Css 模块内容。

开发时我们有样式资源、字体图标、图片资源、html 资源等，webpack 默认都不能处理这些资源，所以我们要加载配置来编译这些资源。提前检查代码的一些隐患，让代码运行时能更加健壮。提前检查代码规范和格式，统一团队编码风格，让代码更优雅美观。开发模式顾名思义就是我们开发代码时使用的模式。1.编译代码，使浏览器能识别运行。2.代码质量检查，树立代码规范。

在开始使用 Webpack 之前，我们需要对 Webpack 的配置有一定的认识。

Webpack 本身功能是有限的:仅能编译JS 中的 ES Module 语法能编译JS 中的 ES Module 语法，还能压缩JS 代码。

webpack的热更新又称热替换（Hot Module Replacement），缩写为HMR。这个机制可以做到不用刷新浏览器而将新变更的模块替换掉旧的模块。HMR的核心就是客户端从服务端拉去更新后的文件，准确的说是 chunk diff (chunk 需要更新的部分)，实际上 WDS 与浏览器之间维护了一个Websocket，当本地资源发生变化时，WDS 会向浏览器推送更新，并带上构建时的 hash，让客户端与上一次资源进行对比。