批量抑制: 一个文件+规则桶中的相同数量的交换是不可视的,并且 --prune-suppressions 无法捕获此情况

ESLint 版本 v10.8.1 ### 您想要解决的问题是什么？ 禁止文件 (eslint-suppressions.json) 记录了每个文件和规则的计数，而不是每个具体违规。文档已经说明了这一点：禁止记录是按文件和规则进行的，而不是按行或代码更改。实际上，这意味着一种特定类型的更改对正常 lint 运行和 --prune-suppressions 来说都是不可见的。 我使用 ESLint 10.8.1 在本地重现了此问题。一个文件 (alpha, beta) 中的两个真实的 no-unused-vars 违规，使用 --suppress-all 进行禁止，计数为 2。然后，我修复了 alpha，并在同一文件 (gamma) 中引入了另一种无关的 no-unused-vars 违规。 beta 仍然存在，未修复。 违规总数仍为 2。 使用禁用文件运行 eslint：清理，退出 0，没有报告。运行 eslint --prune-suppressions：对文件没有变化，没有警告，没有需要删除的内容，因为桶仍然完全满足计数 2，只是覆盖了之前的行组合。 因此，同一规则的一个真正修复和真正回退，在同一文件中完全抵消了，工具中没有命令，甚至不是用于审核禁用文件的命令，都无法显示它。 ### 您认为正确的解决方案是什么？ 我认为按行跟踪永远不是正确的要求，这是一个更大的设计变更，可能不值得作为一个轻量级的批量禁用工具。但是，--prune-suppressions 已经必须重新运行 lint 并与禁用文件进行比较，以决定什么是过时的。它还可以标记，即使只是作为警告，桶中计数仍然相同，但它所覆盖的具体发生情况发生了变化（文件以某种方式更改，触及该规则，尽管记录的计数没有变化）。这不需要长期存储按行的身份，只需在 prune 时间对文件的当前状态和其在最后一次生成或删除禁用时的状态进行差异比较即可。 除此以外，在文档中明确说明 --prune-suppressions 不会捕获此情况，因为目前提到的唯一警告是关于跟踪粒度，而不是关于 audit 命令本身能够和不能够检测到什么。 ### 参与 ### [ ] 我愿意为此更改提交一个 Pull Request。 ### AI 认可 ### [ ] 我没有使用 AI 生成此问题报告。 ### [x] (如果上述未勾选) 我在提交之前已经审阅了 AI 生成的内容。 ### 其他评论 ### 为上下文：我在研究几个不同工具的基准/忽略机制如何处理同一个底层问题时遇到了这个问题，一个不与特定实例绑定的允许违规文件。如果有用，我将此问题更正式地写成文档：https://doi.org/10.5281/zenodo.21908527