warm

WARM

参数

原始参数：$ARGUMENTS

将参数解析为用于比较的基准分支。如果为空，默认使用 main。

目标

根据 WARM 检查评估此分支引入的依赖项——即自分叉于基准分支以来新增或升级的依赖项，并为每个依赖项给出明确结论。涵盖客户端和服务端的依赖项，不限制语言。输出可帮助用户在合并前决定保留哪些新依赖、重新考虑哪些依赖，或固定版本／打补丁。

WARM 代表：

• Worth it?（值得吗？）——自己写大约 20 行代码能替代它吗？如果一个依赖花一个下午就能自己写出来，就不值得增加供应链攻击面。
• Alive?（活跃吗？）——近期是否有提交、维护是否活跃、发布节奏是否正常。一个多年未更新的软件包是个隐患。
• Right-sized?（规模合适吗？）——你是否为了一个函数引入了整套库？依赖的规模应与实际使用情况相匹配。
• Maintained securely?（安全维护吗？）——是否存在已知漏洞（CVE／安全公告）、未修复的问题，或安全记录不佳的维护者。

本检查针对你选择添加的直接依赖。 这四个问题是你对自己的依赖做出的判断，不适用于底层引入的传递依赖。评估新增的直接依赖；只有当传递依赖存在已知安全公告时，才在 M 项下提及。

说明

1. 找出此分支引入的内容

运行 git diff --name-status <base>...HEAD（三点语法——查看此分支自分叉以来的更改），并找出已更改的依赖清单文件。这些文件声明直接依赖，且每个生态系统都有对应文件：

• JS/TS（客户端和服务端）：package.json
• PHP：composer.json
• Python：requirements*.txt、pyproject.toml、Pipfile、setup.py、setup.cfg
• Ruby：Gemfile、*.gemspec
• Go：go.mod
• Rust：Cargo.toml
• Java/Kotlin：pom.xml、build.gradle、build.gradle.kts
• .NET：*.csproj、Directory.Packages.props、packages.config
• Elixir：mix.exs
• Dart/Flutter：pubspec.yaml
• Swift：Package.swift

不要局限于此列表——如果已更改的文件明显是其他生态系统的依赖清单，也应将其视为依赖清单。

对每个已更改的依赖清单，运行 git diff <base>...HEAD -- <manifest>，并提取新增的依赖项行（以及版本升级）。仅使用锁定文件差异（package-lock.json、composer.lock、pnpm-lock.yaml、go.sum、Cargo.lock 等）来确认解析后的版本，以及查找存在安全公告的传递依赖——不要将其作为判断依赖项的依据。

范围：

• 新增的直接依赖 → 完整进行 WARM 评估。
• 已有直接依赖的版本升级 → 仅评估 A 和 M（值得与否、规模是否合适已在首次添加时判断）；注明版本变化。
• 已移除的依赖 → 忽略。

如果没有依赖清单文件发生变化，准确输出：

✅ No dependencies added or upgraded on this branch.

……然后停止。

2. 收集每项依赖的事实

查找所需信息，如实回答每个字母对应的问题。来源优先级如下：

• W（是否值得）：阅读分支实际如何使用这项依赖（用 Grep 查找导入／require／使用位置），并评估你依赖它的范围。在一个组件中使用的日期格式化工具，与在各处都使用的 HTTP 客户端，情况截然不同。
• A（是否活跃）：检查注册表／仓库中的最后发布日期和近期提交活动。使用 npm view <pkg> time.modified／对注册表或仓库页面执行 WebFetch。记录最新发布日期，以及仓库是否已归档。
• R（规模是否合适）：将依赖的体量（子依赖、安装大小、API 广度）与分支实际使用的部分进行比较。只为调用一个辅助函数，就引入一个包含 40 项依赖的框架，并不合适。
• M（维护是否安全）：检查已知安全公告。有生态系统工具时优先使用（npm audit、composer audit、pip-audit）；否则，用软件包名称 +“CVE”／“advisory”执行 WebSearch，并检查安全公告数据库。报告已解析的版本，以及是否存在修复版本。

**诚实规则：**如果无法核实（无网络、注册表无法访问、软件包不明确），请说明检查了什么，并将该字母标为 unknown——绝不编造发布日期、版本或 CVE。

3. 评分并作出决定

对每项依赖的每个字母进行标记：

• ✅ — 该维度没有问题
• ⚠️ — 有值得进一步检查的隐患
• ❌ — 存在实际问题
• ? — 无法核实

然后根据标记给出一个词的结论：

• Keep — 没有 ❌，且最多只有轻微的 ⚠️。
• Reconsider — W 或 R 上有 ❌（你可能不需要这项依赖，或不需要这么大一部分）。
• Patch/Pin — 只有 M 上有 ❌（该依赖有其必要性，但存在安全问题——升级到修复版本或固定版本）。
• Replace — A 上有 ❌（已无人维护）或有多个 ❌。

4. 输出报告

按关注程度排序：结论为 ❌ 的排在最前，其次是 ⚠️，最后是没有问题的 Keep。严格使用以下格式：

## `dayjs` — added to package.json (client)

- ✅ **Worth it** — date parsing used across 6 components; non-trivial to hand-roll correctly
- ✅ **Alive** — last release 2 months ago, active repo
- ✅ **Right-sized** — 2KB, zero dependencies, tree-shakeable
- ✅ **Maintained securely** — no known advisories for 1.11.x

**Verdict: Keep**

## `left-pad` — added to package.json (client)

- ❌ **Worth it** — single use, pads a string; ~5 lines of your own code replaces it
- ⚠️ **Alive** — last release 4 years ago
- ✅ **Right-sized** — tiny, no sub-dependencies
- ✅ **Maintained securely** — no known advisories

**Verdict: Reconsider** — inline it rather than take the supply-chain surface.

## `guzzlehttp/guzzle` — upgraded 7.4.0 → 7.4.5 in composer.json (server)

- ✅ **Alive** — actively maintained
- ❌ **Maintained securely** — 7.4.0 affected by GHSA-xxxx (cookie leak); 7.4.5 fixes it

**Verdict: Patch/Pin** — the upgrade resolves the advisory; keep it.

最后用一行总结：已评估 N 项依赖——X 项 Keep、Y 项 Reconsider、Z 项 Replace/Patch。

规则

• **仅评估该分支引入的内容。**不要审计整个已有依赖树——只检查相较于基分支新增或升级的依赖。
• **直接依赖需完整评估 WARM。**传递依赖只在存在已知安全公告时才列于 M 下。
• **涵盖客户端和服务端。**为每项依赖标注其所在端及所属清单文件，以便用户定位。
• **不限定语言。**以相同方式对待任何生态系统的清单文件。不要因为某项依赖属于你会用不同方式处理的语言，就跳过它。
• **不要编造事实。**发布日期、版本和安全公告必须来自真实查询。无法核实时，标记 ? 并说明你检查了什么。
• **每条要点只写一个隐患。**每个 WARM 字母单独占一行；不要合并两项发现。
• **具体并量化。**例如“最后一次发布于 4 年前”“引入 40 项子依赖”“GHSA-xxxx 在 7.4.5 中修复”，不要写“看起来很旧”或“可能有问题”。
• **结论必须与标记一致。**不要把 ❌ 说成 Keep，也不要把没有问题的依赖模糊处理成 Reconsider。明确说明结论。
• **不写开场白。**从第一个 ## 依赖标题（或无依赖项说明）开始。不要写“以下是 WARM 检查……”。
• **不要修改任何文件。**此技能仅用于评估和报告——不删除依赖、不编辑清单，也不运行安装。