Webpack优化问题

打包流程

webpack 的打包流程大致可以分为以下几个步骤：

初始化：webpack 通过配置文件和 Shell 参数，初始化参数，确定入口文件、输出路径、加
载器、插件等信息。接下来读取配置文件，并合并默认配置、CLI 参数等，生成最终的配置
对象。
编译：从入口文件开始，递归解析模块依赖，找到所有需要打包的模块。之后使用 loader 对
每个模块进行转换，转换成浏览器能够识别的 JS 代码。
构建模块依赖图：webpack 会为每个模块创建一个模块对象，并根据模块的依赖关系，生成
一个模块依赖图（Dependency Graph）。
生成代码块（chunk）：根据入口和依赖图，将所有模块分组，生成一个个包含多个模块的代
码块（chunk），这些 chunk 会根据配置生成不同的输出文件。
输出：将生成的代码块输出到指定的文件夹，并根据配置生成对应的静态资源文件。
插件处理：在整个构建过程中，webpack 会在特定的生命周期钩子上执行插件，插件可以对
打包的各个阶段进行干预和处理。
正是因为了解 webpack 整体的打包流程，所以我发现了很多可以优化的地方，然后进一步着力于
构建的优化，大幅度缩减了构建所花费的时间。

首先使用了一个插件叫 speed-measure-webpack-plugin 来查看构建时间，各个阶段的耗时吧。
分析结果来看的话，babel 编译 js 是比较耗时的，应该是还有一些 loader 处理也比较耗时。这里就有2个优化方案：

swc 替换 babel 进行编译。
thread-loader 来解决 loader 解析耗时问题
还有一些其他的手段来处理。最终的话效果是比较好的，降到了20s左右。

swc

它是 rust 写的 js 的编译器，编译速度非常快，而且能够兼容 babel 插件的配置，这样迁移起来没有什么成本。就这一个替换就减少了一大半的时间，它是占大头的。
我记得去年年底，yyx 说要用 rust 重写 Vite。

thread-loader

它可以通过多线程的来处理 loader 的操作，这样就减少了主线程的负载。这样那些css，图片，vue等loader的总耗时时间也减少了。

剩下的话就是一些细枝末节了，不过也是有一些作用的。

webpack5 新特定是持久化缓存，就是把模块的编译结果，解析结果，还有插件的执行结果缓存起来。后续构建就可以重用了。（这个和 Vite 的依赖预构建很像）
这块提一下吧，之前 Webpack这里也没有做什么特殊处理，就是一些简单的初始配置。后来查阅资料时发现其实在 Webpack4 版本也是有一些优化项的，
比如 cache-loader，在一些开销比较大的 loader 前加是可以将上一个loader 的结果缓存下来，下一次再走这个流程时就会根据一些规则跳过后面 loader 的处理来提高效率。
比如 DllPlugin 和 DllReferencePlugin 搭配使用来，对一些不常用的依赖，单独生成动态链接库，来提高构建速度。

module.exports = {
    // ...
    cache: {
        // 将缓存类型设置为文件系统,默认是memory
        type: "filesystem",
        buildDependencies: {
            // 更改配置文件时，重新缓存
            config: [__filename],
        },
    },
    optimization: {
        // 值为"single"会创建一个在所有生成chunk之间共享的运行时文件
        runtimeChunk: "single",
        moduleIds: "deterministic",
    },
};

hash

还有一个小点，就是这个 hash 的问题。
Webpack下是有3种 hash 的，content-hash，chunk-hash，hash（整个项目），这个是为了在生产环境下利用浏览器缓存机制来优化资源获取的。
开发环境下就不需要哇，本来就会频繁的更改代码。所以就把这个计算 hash 所消耗的时间也给删掉了。