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.
High because unexplained type suppressions accumulate as maintenance debt and mask real type errors that would otherwise be caught before they reach production.
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.
ID: code-quality-essentials.type-safety.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-error over @ts-ignore — if the check passes without an actual error, @ts-expect-error will itself error, preventing comment rot. Also check for patterns like as unknown as T casts and as any casts in the same pass, which serve the same "silence the type checker" purpose and should be noted (though only @ts-ignore is the pass/fail criterion here).
Pass criteria: Enumerate all relevant code locations. No @ts-ignore comments 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-ignore without explanation, or more than three total @ts-ignore comments 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;