No @ts-ignore comments without explanation
Why it matters
A bare @ts-ignore tells TypeScript to stop checking the next line with no record of why. When the underlying problem is later fixed (a third-party type definition is updated, a library is upgraded), the suppression remains silently in place — a form of type-safety debt that accumulates until something breaks. ISO 25010:2011 §6.5.2 classifies unexplained suppressions as a maintainability defect. More than three @ts-ignore comments in a codebase is a signal that developers are routinely bypassing the compiler rather than fixing the underlying type issues.
Severity rationale
High because unexplained type suppressions accumulate as maintenance debt and mask real type errors that would otherwise be caught before they reach production.
Remediation
For each @ts-ignore, evaluate whether the underlying type error can be fixed properly. If suppression is genuinely necessary, replace it with @ts-expect-error and a comment — @ts-expect-error will itself error if the problem is later resolved, preventing comment rot.
// Before (silent suppression, no context):
// @ts-ignore
element.customProperty = value;
// After (documented, self-removing when the type is fixed):
// @ts-expect-error: missing from HTMLElement types, tracked in #42
element.customProperty = value;
For third-party libraries with incorrect types, prefer module augmentation or contributing a fix to @types/ over suppressing the error.
Detection
-
ID:
no-ts-ignore -
Severity:
high -
What to look for: Search all TypeScript source files (excluding
node_modules, test fixtures, and generated files) for the string@ts-ignore. For each occurrence found, check whether an explanatory comment appears on the same line or the line immediately above, explaining specifically why the suppression is necessary and what issue it works around. Prefer@ts-expect-errorover@ts-ignore— if the check passes without an actual error,@ts-expect-errorwill itself error, preventing comment rot. Also check for patterns likeas unknown as Tcasts andas anycasts in the same pass, which serve the same "silence the type checker" purpose and should be noted (though only@ts-ignoreis the pass/fail criterion here). -
Pass criteria: Enumerate all relevant code locations. No
@ts-ignorecomments exist, or each occurrence is accompanied by an explicit comment explaining the specific reason (e.g.,// @ts-ignore: third-party type definitions don't include this property yet) with at least 1 verified location. -
Fail criteria: One or more bare
@ts-ignorewithout explanation, or more than three total@ts-ignorecomments regardless of explanation. -
Skip (N/A) when: Project has no TypeScript files.
-
Detail on fail:
"Found N instances of @ts-ignore without explanation in source files; use @ts-expect-error with a comment instead"(substitute actual count) -
Remediation: For each
@ts-ignore, evaluate whether the type error can be fixed properly. If a third-party library has incorrect types, consider submitting a fix to@types/or using module augmentation. If suppression is genuinely unavoidable:// Before (silent suppression, no context): // @ts-ignore element.customProperty = value; // After (documented, uses expect-error which errors if fixed): // @ts-expect-error: missing from HTMLElement types, tracked in #42 element.customProperty = value;
External references
- iso-25010:2011 · maintainability.analysability — Maintainability — Analysability
Taxons
History
- 2026-04-18·v1.0.0·Initial import from code-quality-essentials·automated