Skip to content
Latchkey

TypeScript "Found N errors" - Make the Build Fail Loudly in CI

tsc prints Found N errors and exits non-zero when type-checking turns up problems. In CI that is exactly what you want - but only if you actually run tsc --noEmit and let its exit code fail the job.

What this error means

The type-check step fails with a list of errors and a trailing Found N errors in M files. Each error has its own TS code; the summary is the count, not the cause.

tsc output
src/a.ts:3:7 - error TS2322: Type 'string' is not assignable to type 'number'.
src/b.tsx:8:1 - error TS2304: Cannot find name 'useStat'.

Found 2 errors in 2 files.

Errors  Files
     1  src/a.ts:3
     1  src/b.tsx:8

Common causes

Real type errors across the project

Each listed error is a distinct problem (TS2322 mismatch, TS2304 missing name, etc.). The "Found N errors" line just totals them; fix them one TS code at a time.

Type-check not gating the pipeline

A build that emits despite errors (or a missing tsc --noEmit step) lets type errors slip through. Bundlers like Vite/esbuild transpile without type-checking, so types must be checked separately.

How to fix it

Run a dedicated type-check that fails CI

Add a non-emitting check and let its exit code gate the job.

Terminal
# package.json: "type-check": "tsc --noEmit"
npm run type-check   # exits non-zero on any error, failing the job

Triage errors by code

  1. Read each error's TS code - they map to distinct fixes (TS2307 install, TS2345 type fix, etc.).
  2. Use tsc --noEmit --pretty false for compact, grep-able output in CI logs.
  3. Fix highest-frequency codes first; one root cause often clears many errors.

How to prevent it

  • Run tsc --noEmit as a required CI step, separate from the bundler build.
  • Enable strict so errors are caught consistently across machines.
  • Pin the TypeScript version so local and CI report the same errors.

Related guides

Tired of flaky CI? Latchkey auto-heals failed jobs and retries them for you. Start free →