解读

在国内前端团队里，私有 Grunt 插件通常以 @company/grunt-xxx 的形式发布到私有 npm 仓库（Verdaccio、Nexus、CNPM 等）。虽然代码不对外，但项目仍然要经历「多人协作、CI 流水线、灰度部署」等标准流程。
面试官问“为什么还要写 peerDependencies”，并不是在考察你会不会写 JSON，而是在确认你是否理解**“版本一致性”与“依赖地狱”**在工程化场景下的代价。
一句话：私有≠随意，peerDependencies 是把“运行时的版本约定”提前到“安装时”就暴露出来，避免上线前最后一刻才爆炸。

知识点

1. Grunt 插件的运行机制
   插件本身只导出任务函数，真正的运行上下文由调用方 node_modules 里的 grunt 主包提供。
   因此插件代码里 require('grunt') 拿到的实例必须与项目里安装的 grunt 是同一个内存对象，否则会出现任务注册不上、API 不兼容等问题。

2. peerDependencies 的语义
   它声明的是**“我运行时所在宿主必须提供的依赖”，而不是“我亲自去安装的依赖”。
   当 npm 发现宿主目录下的 grunt 版本与插件声明的区间不匹配时，会直接阻断安装**并给出清晰的错误日志，把问题留在开发阶段。

3. 国内私有仓库的镜像策略
   很多公司为了提速，会把公网包缓存到内网。若插件里不写 peerDependencies，CI 第一次装包时会把 grunt 重复拉进插件自己的 node_modules，导致两份 grunt 并存；本地开发时又因为缓存路径不同表现正常，测试环境才暴露，排查成本极高。

4. 合规与审计要求
   金融、政务类项目上线前要做三方件清单审核。peerDependencies 能把“我依赖谁、谁依赖我”梳理成静态可扫描的声明，方便安全团队直接生成 SBOM，否则只能人肉反查代码，耽误发版窗口。

答案

“私有插件仍然必须提供 peerDependencies，核心原因是把‘运行时对 grunt 主包的单例要求’提前到安装阶段就强制校验。
一方面，插件在代码里只负责导出任务，真正执行时依赖调用方提供的 grunt 实例；如果版本不一致，API 差异会导致任务注册失败或运行期崩溃。
另一方面，国内公司普遍使用私有 npm 仓库与 CI 缓存，不写 peerDependencies 极易出现多份 grunt 并存的幽灵依赖，问题在本地被掩盖，上线前才集中爆发，排查成本极高。
加上金融、政务等项目需要合规审计，peerDependencies 能生成静态可扫描的依赖图谱，减少安全团队的人工反查时间。
因此，即使代码不对外发布，也要用 peerDependencies 把版本约束写死，把风险左移到开发阶段，保证多人协作、持续集成、灰度部署全链路的一致性。”

拓展思考

1. 如何锁定 grunt 插件的 peer 范围？
   先跑 npm ls grunt 列出公司所有在役项目的 grunt 版本区间，取最小公共交集；如果跨度太大，把插件拆成两个 major 版本，分别对应 1.x 与 2.x 的 grunt，用 major 号表达 Breaking，让宿主项目按需升级。

2. 与 devDependencies 的区别实战
   在插件仓库自身，devDependencies 里放 grunt 仅用于单元测试，而 peerDependencies 才是给“被安装方”看的约束。
   很多候选人把 grunt 同时写进 dev + peer，却忘了在 CI 里加 --legacy-peer-deps，结果测试通过、业务项目装包失败；正确做法是CI 脚本显式安装与 peer 区间匹配的 grunt 版本，保持两边一致。

3. 未来迁移到 ESM 与 pnpm 的注意事项
   国内已开始试点 pnpm + ESM 的严格依赖隔离。peerDependencies 的校验规则比 npm 更严，如果插件里用了 import grunt from 'grunt'，而宿主没提供，会直接抛 ERR_MODULE_NOT_FOUND。
   因此私有插件要提前把**“grunt” 加入 peerMeta**，并在文档里写明**“宿主项目必须安装 grunt >=1.6.0”**，否则升级到 pnpm 后全公司流水线会集体报错，回滚窗口只有 30 分钟，代价更高。