前言
DllPlugin 和 DllReferencePlugin 这两个webpack 的工具,在我负责的一个项目中有用到,具体的使用过程,可以查看我之前写的文章: 微前端(乾坤)项目下,如何使用 dllplugin 打包抽取公共依赖及其中遇到的问题
背景
我目前开发的这个微前端项目,它是把所有的应用到放在同一个目录下。这也导致在维护多个应用的时候,我需要把各个应用的依赖 node_modules 安装一下,结果就使得整个项目文件体积特别大。为了减少重复的 node_modules ,我根据依赖的引入规则(直接引入的依赖会先找当前目录的 node_modules,找不到就往父文件夹找,以此类推,直到硬盘的根目录下和 npm 的环境变量指向的目录),把公共的 node_modules 依赖,放到了项目的根目录下,这样每个子应用就不用去安装 dependences 的依赖,减小了项目一半的体积。
问题
基于上诉背景,我重新打包后发现,我用 dllplugin 提取公共依赖,居然没有减小项目打包后体积。一个子应用在成功使用 dllplugin 的依赖后应该只有2、3 m左右,但现在变回了之前没用 dllplugin 依赖情况,一个子应用打包后的体积在 7、8 m左右。很明显,打包时没有忽略掉那些应该使用 dllplugin 的依赖,而是直接把它们打包了。
解决
在查看文档时,我看到了一个关键的配置 context:
DllPlugin和DllReferencePlugin都有这个配置。根据官方文档描述,这是 manifest (或者是内容属性)中请求的上下文,并且很多人都会把这个值设置成 path 的**__dirname** 。
对于请求的上下文这个概念,第一次看的时候,也不是很明白,但我的直觉告诉我,这是解决我当前问题的关键。于是经过几次尝试后,得出结论:
- DllPlugin的context
context 指定的路径,是要包含打包成 dll js文件的依赖存在于的 node_modules - DllReferencePlugin的context
除了给 manifest (或者是内容属性)中请求的上下文,还具有让 webpack 得知什么依赖是可以忽略打包的。
两个插件的 context 的值,指向的路径,即所谓的上下文,必须包含引用依赖的 node_modules。否则 DllReferencePlugin 无法帮助子应用忽略已使用 dll 打包的依赖,将会直接把依赖打包,而 DllPlugin 的 context 也会影响到 DllReferencePlugin context。