What You Refuse to Check Decides the Quality of a Linter

说明与用途

通过仅在官方文档明确说明时添加规则、强制包含来源链接以及仅使用错误/警告级别，构建一个避免误报的 linter。

问题

Developers struggle to build linters that avoid false positives while still catching real issues, leading to loss of trust and CI failures.

结果

The linter achieves zero false positives on valid configurations, maintains high trust, and avoids CI removal.

工作流

• 1. Define a rule only if the official documentation explicitly states it as an error, warning, or ignored case.
• 2. Require each finding to include a "because" field with a source URL.
• 3. Enforce the source URL requirement in tests; any finding without it fails the suite.
• 4. Avoid rules for ambiguous or undocumented features (unknown keys, model names, complex path patterns, non‑standard booleans).
• 5. Use only two severities: "error" for documented violations and "warn" for deprecated or future‑breaking cases.
• 6. Run tests with a deliberately valid configuration that includes edge cases; expect zero findings.
• 7. If any finding appears on the valid config, reconsider the rule or its implementation.

证据

One false positive is enough to get the tool thrown out

来源

Only check what the official documentation states outright — as an error, as skipped, or as ignored.

来源

A single finding from any of those means the design is wrong.

来源