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.
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:8Common 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.
# package.json: "type-check": "tsc --noEmit"
npm run type-check # exits non-zero on any error, failing the jobTriage errors by code
- Read each error's TS code - they map to distinct fixes (TS2307 install, TS2345 type fix, etc.).
- Use
tsc --noEmit --pretty falsefor compact, grep-able output in CI logs. - Fix highest-frequency codes first; one root cause often clears many errors.
How to prevent it
- Run
tsc --noEmitas a required CI step, separate from the bundler build. - Enable
strictso errors are caught consistently across machines. - Pin the TypeScript version so local and CI report the same errors.