一次 webpack dll 无效的场景原因分析与解决

2022-12-14 0 条评论 717 次阅读被赞了 0 次

在对一个庞大的 Angular 项目进行构建优化时，为其增加了 webpack dll 配置。但是执行后发现 dll 没有生效，配置在 dll 中的依赖仍然会被打包在运行时 chunks 当中。

经过调试 DllReferencePlugin 发现 manifest 中的路径似乎不太对。打开 manifest.json 文件，发现其中的依赖路径都是类似这样的：

“content”:{“../node_modules/@angular/common/fesm2020/common.mjs”:{“id”:”./node_modules/@angular/common/fesm2020/common.mjs”,

显然，content 中的模块 key 前缀都是以 ../node_modules 开头，而实际项目中的模块 ID 在 resolve 后都是以 ./node_modules，于是相同的模块实际上 key 不一致，自然无法匹配了。

仔细分析了一下 webpack.dll.config.js 的配置，才发现了端倪：

new webpack.DllPlugin({
  context: __dirname,
  path: path.join(output, '[name]-manifest.json'),
  name: '[name]_library',
}),

从上面的配置中可以看到，context 部分根据 __dirname 设置，这里是参考官方文档的设置方式。但是我在创建该配置后即将它移动到了项目根目录的 config 目录下，于是 context 变为了 config 目录。

解决办法则是修正它为当前目录（与webpack.config.js一致即可），或者删除它（默认使用 webpack context）。示例：

new webpack.DllPlugin({
  context: process.cwd(),
  path: path.join(output, '[name]-manifest.json'),
  name: '[name]_library',
}),

小结：

该问题的原因虽然简单，但是在一开始并未意识到是配置的原因，以为是 angular-cli 构建流程中的逻辑导致，由于查找方向出现了偏差，所以浪费了较多的时间。实际上遇到此类问题，还是要从 debugger 单步调试入手，看上去稍微繁琐，实际上由于可以清晰的定位分析，更为为节省时间。

志文工作室