修复 Flows 应用依赖问题：漏洞、过时包…

在修复 Flows 应用的依赖问题时，全面查找并修复漏洞、过时包、废弃依赖、许可证问题与供应链风险，并生成 review-packages.md 产物。

适用场景

解决思路

1. 读取并列出所有依赖：用 node 脚本读取 package.json，分别打印 dependencies 和 devDependencies 的名称与版本，记录总数。
2. 查询 npm 元数据并更新过时包：对每个包收集最新版本、周下载量、最后发布时间、是否废弃；用 npm view <package-name> --json 获取信息，用 curl -s "https://api.npmjs.org/downloads/point/last-week/<package-name>" 获取周下载量；批量查询时用 node 脚本循环执行 npm view。
3. 更新过时包：对落后超过 1 个 major 版本的包执行 pnpm update <package>@latest；对落后 1 个以上 minor 版本的包执行 pnpm update <package>；更新后运行 pnpm install 和 pnpm run build 验证，若 major 更新导致构建失败则回滚该更新并记为手动修复项。
4. 运行安全审计并修复漏洞：执行 pnpm audit --json 或 npm audit --json，以及 pnpm audit --prod --json 或 npm audit --production --json；解析 JSON 中的严重级别计数和每个漏洞详情（包、严重级别、标题、修复版本、公告 URL）；任何有已知 CVE 的包在健康列自动判为 Fail。
5. 修复漏洞：运行 pnpm audit fix 自动修复；对无法自动修复的高危/严重 CVE，手动将 package.json 中易受攻击的包更新到已修复版本并运行 pnpm install；若修复版本有破坏性变更，做最小代码适配；若漏洞在传递依赖中，用 package.json 中的 pnpm.overrides 强制指定已修复版本，例如 {"pnpm":{"overrides":{"vulnerable-package":">=2.1.0"}}}；修复后重新运行 pnpm audit 确认已解决，并运行 pnpm run build 验证。
6. 分配健康评分并修复 Fail 级包：Pass 标准为周下载量 >100k 且 12 个月内有更新且未废弃且版本为当前或接近当前（落后不超过 1 个 major）；Warn 标准为周下载量 10k–100k 或超过 12 个月未发布或落后超过 1 个 major；Fail 标准为周下载量 <10k 或 2 年以上未更新或已废弃或有已知 CVE；边界情况：@cognite/* 包即使下载量低也信任，@types/* 包信任 DefinitelyTyped 并关注版本是否与主包匹配，新发布包（<6 个月）标记为 Warn 供审查而非因低下载量自动 Fail。
7. 替换 Fail 级包：若已废弃，找到并安装推荐的替代品，更新代码库中所有 import；若 2 年以上无人维护，找到功能等价且活跃维护的替代品并替换；若下载量低且非 @cognite/*，评估是否真正需要，若有原生 JS/TS 等价实现或功能简单则移除依赖并内联实现；每次替换后运行 pnpm install 和 pnpm run build 验证。
8. 检查供应链风险并缓解：用 node 脚本检查每个包的 install 脚本（preinstall、install、postinstall），打印含风险脚本的包；检查维护者极少的包（信息性，不阻塞）。
9. 评估并缓解 install 脚本风险：对每个含 install 脚本的依赖判断脚本是否合法（如 sharp、esbuild、better-sqlite3 的原生模块编译）；已知构建工具和原生模块包预期有 install 脚本；若包不是已知构建工具且有可疑 install 脚本，替换为更安全的替代品，替换后运行 pnpm install 和 pnpm run build 验证。
10. 检查许可证兼容性并替换有问题的包：用 npx license-checker --summary 或 node 脚本列出所有许可证；Flows 应用（商业分发）可接受的许可证为 MIT、Apache-2.0、BSD-2-Clause、BSD-3-Clause、ISC、0BSD、Unlicense、CC0-1.0；需要法律审查的许可证为 GPL-2.0、GPL-3.0、LGPL-2.1、LGPL-3.0、AGPL-3.0、MPL-2.0、EUPL-1.1 以及任何 UNKNOWN 或缺失许可证。
11. 替换有问题的许可证包：对生产依赖中具有 copyleft 许可证（GPL、AGPL）或未知许可证的包，找到 MIT/Apache-2.0 许可的替代品并替换，更新代码库中所有 import；对 devDependencies 中的 copyleft 许可证风险较低但仍需标记；每次替换后运行 pnpm install 和 pnpm run build 验证。
12. 生成 review-packages.md 产物（修复后状态）：在所有修复应用后重新运行元数据查询以捕获修复后状态，按 Flows 应用审查流程要求的格式输出，包含 Dependencies 表、Dev Dependencies 表、Security audit 表、Vulnerabilities 表、License summary 表、Supply-chain flags 表，每行含 Package、Used version、Latest、Weekly downloads、Last published、Deprecated、CVEs、Health 字段。
13. 报告剩余问题：汇总已修复项（更新的包数量与版本变化、解决的 CVE、替换的废弃依赖、解决的许可证问题）和剩余无法自动修复的问题（major 更新带来的需手动适配的破坏性变更、需法律审查的许可证如传递依赖中的 LGPL、无维护替代品的包、尚无修复版本的漏洞），对每个剩余项说明为何无法自动修复以及应用作者需要做什么。
14. 给出最终健康结论：说明修复后 Pass/Warn/Fail 的数量、解决了多少问题、以及需要应用作者手动处理的剩余项。

适用边界 · 注意事项

• 不适用于非 Flows 应用或非 Node.js/pnpm 项目（技能依赖 package.json、pnpm/npm 与 Flows 审查流程）。
• 不适用于需要法律团队最终裁决的许可证问题——技能只能标记并替换，无法替代法律审查。
• 不适用于尚无修复版本的漏洞或无维护替代品的包——这些只能报告，无法自动修复。