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

在对一个庞大的 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 单步调试入手,看上去稍微繁琐,实际上由于可以清晰的定位分析,更为为节省时间。

  • https://webpack.js.org/plugins/dll-plugin/#dllreferenceplugin
点赞 (0)

发表回复

您的电子邮箱地址不会被公开。 必填项已用 * 标注

Captcha Code