网站建设选谋者,免费好用的网站管理系统,vi设计作品赏析,有了页游源代码如何做网站目录 打包流程swcthread-loaderhash升级插件 打包流程
webpack 的打包流程大致可以分为以下几个步骤#xff1a;
初始化#xff1a;webpack 通过配置文件和 Shell 参数#xff0c;初始化参数#xff0c;确定入口文件、输出路径、加 载器、插件等信息。接下来读取配置文件… 目录 打包流程swcthread-loaderhash升级插件 打包流程
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: {// 将缓存类型设置为文件系统,默认是memorytype: filesystem,buildDependencies: {// 更改配置文件时重新缓存config: [__filename],},},optimization: {// 值为single会创建一个在所有生成chunk之间共享的运行时文件runtimeChunk: single,moduleIds: deterministic,},
};hash
还有一个小点就是这个 hash 的问题。 Webpack下是有3种 hash 的content-hashchunk-hashhash整个项目这个是为了在生产环境下利用浏览器缓存机制来优化资源获取的。 开发环境下就不需要哇本来就会频繁的更改代码。所以就把这个计算 hash 所消耗的时间也给删掉了。
升级插件
最后一个的话是一个插件的升级。因为本来就升级到 Webpack5 了嘛对应的一些插件肯定也要去兼容一下其中有一个 terser-webpack-plugin 的插件它是用来做压缩的。然后就看到它的更新日志上好像是从 5.x 版本也引入了 swc 压缩器升级后发现速度又变快了。
整体来说主要用到了5个技术
SWCthread-loaderwebpack5的持久化缓存hashterser-webpack-plugin 其实看 CHANGE_LOG 有时是可以发现一些被修复的问题的比如 element-ui 升级版本对 table 组件的问题。 依赖对 node 版本的需求。也可以说下查看 npm 依赖的 CHANGE_LOG 大概就是这样。 以上。 之后详细总结。
