TypeScript compilation produces no errors
Why it matters
Every @ts-ignore comment suppresses a real type error — it does not fix the underlying type mismatch, it hides it. The bug still exists at runtime; TypeScript just stops warning about it. Three or more suppressions signal a pattern of bypassing the type system rather than fixing it, which compounds: developers learn that @ts-ignore is an acceptable solution, and the count grows. ISO 25010 maintainability.modifiability degrades because refactoring becomes unpredictable — suppressions hide which code actually works.
Severity rationale
Critical because TypeScript suppression comments allow real type errors to reach production silently, bypassing the primary safety mechanism TypeScript provides.
Remediation
Find every suppression in application source files:
grep -r "@ts-ignore\|@ts-nocheck" src/
For each one: if it suppresses a genuine type error in your code, fix the underlying type. If it works around a bad type from a third-party library, use a specific cast (value as SpecificType) rather than suppressing the whole line. Prevent new suppressions with:
"@typescript-eslint/ban-ts-comment": ["error", { "ts-ignore": "allow-with-description" }]
This forces every remaining suppression to include a comment explaining why it exists.
DetectionPro
The detection method for this pattern is part of AuditBuffet Pro.
The full method (what to look for, pass and fail conditions, and how results get reported) ships inside the Code Maintainability Audit. The pattern definition, severity rationale, and remediation remain openly licensed under CC-BY-4.0.
External references
- iso-25010:2011 · maintainability.analysability — Analysability
- iso-25010:2011 · maintainability.modifiability — Modifiability
Taxons
History
- 2026-04-18·v1.0.0·Initial import from code-maintainability·automated