The `@ts-ignore` vs. `@ts-expect-error` Dilemma: Missing a Warning-Only Redundancy Check

⭐ Suggestion

We propose introducing a mechanism (either a new directive or a configuration option) that provides a Warning-level diagnostic when a type suppression comment is unused.

This feature is needed to fill the gap between the permanently silent @ts-ignore and the build-breaking @ts-expect-error. The goal is to allow active awareness of stale code without halting the CI pipeline.

Specifically, we request one of the following:

1. A New Directive: A directive functionally equivalent to // @ts-expect-error, but which emits its unused check (the equivalent of TS2578) as a Warning.
2. A Compiler Flag: An option to explicitly downgrade the severity of the TS2578: Unused '@ts-expect-error' directive diagnostic from Error to Warning.

📃 Motivating Example

For development teams managing projects with frequent dependency updates, the choice between @ts-ignore and @ts-expect-error is a risk management problem.

Current strictness dictates that a successful, external fix to a dependency's type definition must immediately break our codebase to enforce comment removal. This high-cost cleanup process often drives teams toward the permanently unsafe @ts-ignore to maintain CI stability.

A warning-level check removes this friction. It guarantees that temporary suppressions are never forgotten (like @ts-expect-error) while ensuring that the build process remains robust and responsive to upstream improvements (unlike @ts-ignore). This allows teams to prioritize cleaning up stale suppressions as a continuous maintenance task, rather than a critical, synchronous intervention.

💻 Use Cases

1. What do you want to use this for?

   This feature would be used primarily for temporary suppressions that are dependent on frequently changing external code (such as library dependencies or rapid internal package updates), ensuring the temporary fix is never forgotten while allowing the system to tolerate the external fix being resolved.

2. What shortcomings exist with current approaches?

   The shortcomings are the two extremes created by the current directives:

   Directive	Does It Alert When Unused?	Unused Diagnostic Output	Workflow Impact
   @ts-ignore	No	None	Too Loose: Encourages type safety neglect and hides new, unrelated bugs.
   @ts-expect-error	Yes	Hard Compilation Error (TS2578)	Too Strict: Halts the entire build/CI pipeline when the suppression becomes unused.

   When a developer explicitly or implicitly updates a dependency and the underlying type error is resolved, the resulting TS2578 error immediately fails the build. This forces a synchronous context switch and cleanup task, making it an impractical solution for temporary dependency workarounds in high-velocity teams.

3. What workarounds are you using in the meantime?

   The current workarounds leave much to be desired:

   • Falling back to the permanently unsafe @ts-ignore to maintain CI stability.
   • Implementing brittle internal patches to TS to intercept and programmatically downgrade the severity of the TS2578 error

🔍 Search Terms

@ts-expect-error @ts-ignore warning

✅ Viability Checklist

• This wouldn't be a breaking change in existing TypeScript/JavaScript code
• This wouldn't change the runtime behavior of existing JavaScript code
• This could be implemented without emitting different JS based on the types of the expressions
• This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, new syntax sugar for JS, etc.)
• This isn't a request to add a new utility type: https://github.com/microsoft/TypeScript/wiki/No-New-Utility-Types
• This feature would agree with the rest of our Design Goals: https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals

未指定文件或测试。首先跟踪现有的 @ts-expect-error 和 TS2578 诊断处理，然后比较提议的指令和编译器选项设计。当未使用的抑制产生警告级别的诊断，且不会导致 build 失败时，即视为完成。