NPM 包依赖分析器

你在排查什么

当一个项目从几十个依赖膨胀到上千个时，package.json 里的直接依赖只是冰山一角。真正出问题的是水面下的部分：某个传递依赖把整个项目拖进 GPL 许可证冲突，某个间接依赖与另一个包版本互相引用形成循环，或者新引入的库让 bundle 体积凭空多出几百 KB，而你完全看不到是谁引入的。

依赖树越深，这类问题越难靠 npm ls 肉眼排查。

这个技能如何工作

它直接在 Node.js 进程里调用官方工具链，而不是自己解析 package-lock.json：

• 获取元数据：通过 npm-registry-fetch 从 registry 拉取包信息，走的是和 npm install 同一套网络路径。
• 提取依赖树：利用 pacote 处理 tarball 与 manifest 的获取与校验。
• 重构依赖图：借助 arborist 构建完整的依赖图，它能识别实际安装结果与声明之间的偏差。

在此基础上，技能做三类检查：

• 循环依赖检测：遍历依赖图，找出包之间形成环路的路径，而不是只看直接依赖的声明。
• 许可证冲突识别：对比各包的 license 字段，标记与项目许可策略不兼容的条目。
• 体积影响评估：调用 bundlephobia API 查询每个包的压缩体积，定位对产物大小贡献异常的依赖。

适用边界与注意点

• 它分析的是安装后的真实依赖图，因此锁文件是否与 package.json 一致会直接影响结果准确性。
• 对于走私有 registry 或 Docker 内离线环境的模块，需要保证 npm-registry-fetch 能访问到对应源，否则部分包元数据会拉取失败。
• bundlephobia 的体积数据来自公共 registry 的打包结果，私有包或自定义构建配置下的体积可能与此不同。
• 许可证检查基于包声明的 license 字段，未声明或声明不规范的包需要人工确认。