DllPlugin和DllReferencePlugin中的context

前言

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。