TypeScript compilation produces no errors

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.

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.

• ID: code-maintainability.code-hygiene.typescript-compiles

• Severity: critical

• What to look for: Check whether the project builds without TypeScript errors. Look for signals: check package.json scripts for a type-check or tsc --noEmit script. If the project is Next.js, next build runs TypeScript checks by default. Look for any // @ts-ignore or // @ts-nocheck comments in source files — these suppress errors and indicate known type violations being hidden. Count them if found. Also check tsconfig.json for "skipLibCheck": true (acceptable for library types but not a substitute for fixing app code errors) and "noEmit": true (good practice for type-checking without output).

• Pass criteria: Count every @ts-ignore and @ts-nocheck comment in application source files (not .d.ts or node_modules). Either: no @ts-ignore or @ts-nocheck comments found in application source code AND the project has a type-check script that is expected to pass, OR the build script is confirmed to pass TypeScript checks. No more than 2 suppressions across all source files. Report even on pass: "Found X TypeScript suppression comments across Y source files."

• Fail criteria: 3 or more @ts-ignore or @ts-nocheck comments found in application source files (not in .d.ts declaration files or third-party code). These indicate suppressed type errors that could hide real bugs.

• Cross-reference: For TypeScript strict mode configuration, see the typescript-strict check in this audit.

• Error when: Cannot access source files to check for TypeScript suppressions.

• Skip (N/A) when: The project uses JavaScript with no TypeScript. Signal: no tsconfig.json and no .ts/.tsx files.

• Detail on fail: "7 @ts-ignore comments found across application source files: 3 in lib/api.ts, 2 in components/DataTable.tsx, 2 in app/dashboard/page.tsx. These suppress TypeScript errors that likely represent real type mismatches." or "@ts-nocheck at the top of lib/payments.ts — entire file excluded from type checking."

• Remediation: @ts-ignore comments are a red flag — they mean a type error exists but is being hidden rather than fixed. Each one is a potential runtime bug in disguise.

  To find all suppressions:

  grep -r "@ts-ignore\|@ts-nocheck" src/
  

  For each suppression, understand why it exists:

  1. If it's a genuine type error in your code → fix the underlying type issue
  2. If it's a bad type from a third-party library → use a more specific cast: value as SpecificType
  3. If you're unsure what type something should be → use unknown and narrow it

  Set up @typescript-eslint/ban-ts-comment rule to prevent new suppressions:

  "@typescript-eslint/ban-ts-comment": ["error", { "ts-ignore": "allow-with-description" }]