如何修复Dependabot告警的npm传递依赖漏洞

核心疑问直接答复 #

手动在package.json根依赖中声明高版本lodash的覆盖效果并不稳定，不推荐直接这么操作：

• npm 3+、yarn v1、pnpm的默认扁平化安装逻辑下，根目录直接声明的依赖会被优先提升到node_modules顶层，子依赖在自身嵌套目录找不到对应版本时会向上查找，确实有概率加载到你声明的4.17.21版本，但这个行为受依赖安装顺序、其他包的依赖声明影响，没有确定性，很可能某次安装后版本就回退到存在漏洞的2.4.2。
• 跨大版本升级lodash本身存在兼容风险：2.x到4.x的lodash存在大量不兼容的API变更，直接替换版本可能导致zip-folder运行时报错，必须做完整功能验证。

另外你提到的Dependabot不自动生成PR是正常行为：这类上游依赖长期不维护、跨大版本的传递依赖冲突，Dependabot无法判断强制升级是否会破坏代码运行，因此只会推送告警，不会自动创建升级PR。

按优先级排序的可行解决方案 #

• 第一优先级：替换停滞维护的依赖包
  zip-folder最新版本发布于7年前，长期不更新依赖，本身已经属于高风险的无人维护包。最彻底的解决方案是直接替换成维护活跃的同能力方案：可以用Node.js原生的压缩相关API、或是当前仍在持续维护的压缩库实现文件夹压缩逻辑，从根源上消除老旧传递依赖带来的漏洞问题，不需要再迁就不更新的上游包。
• 第二优先级：使用官方配置强制锁定依赖版本（需做兼容验证）
  如果短期内无法完成依赖替换，用包管理器原生提供的强制版本覆盖能力替代手动在根依赖声明版本，版本锁定的确定性为100%：
  如果你使用npm 8.3.0及以上版本，直接在package.json中添加overrides字段：

  {
    "overrides": {
      "lodash": "4.17.21"
    }
  }
  

  yarn用户可使用resolutions字段实现相同效果，pnpm同样原生支持overrides配置。添加配置后重新执行依赖安装命令，所有依赖层级下的lodash都会被强制替换为你指定的修复版本，不会出现版本随机浮动的问题。
  注意：强制替换后必须完整覆盖测试所有涉及zip-folder的业务逻辑，确认跨大版本的lodash不会导致功能异常。
• 临时兜底方案：自行维护兼容的fork版本
  如果测试后发现lodash 4.x和现有版本的zip-folder不兼容，可以自行forkzip-folder仓库，修改其依赖声明为修复版lodash，适配调整不兼容的API逻辑后，在项目中直接引用你维护的fork版本即可，后续再逐步迁移到其他维护正常的压缩库。

内容的提问来源于stack exchange，提问作者DevDenim007