← Lessons

quiz vs the machine

Gold1350

Frontend

Type Checking In CI

Run the type checker as a build gate to catch errors before merge.

4 min read · core · beat Gold to climb

Why a separate CI step

Editors show type errors as you work, but a teammate can merge code their editor flagged or that only fails in a full project check. A dedicated CI step runs the whole project type check and fails the build on any error.

What it guards

  • Catches mismatched props and wrong function arguments before runtime.
  • Prevents an unsound change in one file from silently breaking another.
  • Keeps the codebase green so types stay trustworthy.

Make it fast and reliable

  • Use incremental type checking to reuse prior results.
  • Run it in parallel with lint and tests as separate jobs.
  • Treat the type check as non negotiable rather than a warning.

Strictness pays off

Turning on strict options surfaces null and undefined mistakes early. The CI gate then prevents anyone from regressing that strictness.

A green type check across the whole project is a strong, cheap signal of correctness.

Key idea

A whole project type check in CI blocks merges on type errors that editors alone can miss.

Check yourself

Answer to earn rating on the learn ladder.

1. Why is a CI type check needed if editors already show type errors?

2. How can the CI type check be kept fast?