# TypeScript compilation produces no errors

- **Pattern:** `ab-000680` (`code-maintainability.code-hygiene.typescript-compiles`)
- **Severity:** critical
- **Lifecycle:** active
- **Last modified:** 2026-04-18
- **Canonical URL:** https://auditbuffet.com/patterns/ab-000680
- **License:** CC-BY-4.0 — attribute to AuditBuffet Pattern Catalog (https://auditbuffet.com/patterns/ab-000680)

## 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:

```bash
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:

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

This forces every remaining suppression to include a comment explaining why it exists.

## Detection

- **ID:** `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:
  ```bash
  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:
  ```json
  "@typescript-eslint/ban-ts-comment": ["error", { "ts-ignore": "allow-with-description" }]
  ```

## External references

- iso-25010 maintainability.analysability
- iso-25010 maintainability.modifiability

Taxons: code-quality

HTML version: https://auditbuffet.com/patterns/ab-000680