Type Checking, Tests, and Linting
Type checking, runtime tests, and linting catch different classes of defects. Type checking verifies static contracts; unit and integration tests exercise runtime behavior; lint rules enforce conventions and flag suspicious patterns. None replaces the others.
Run all relevant checks in CI. If a test runner or bundler transpiles TypeScript without full type checking, add a separate type-check script. Keep compiler and lint rules aligned with the team's migration stage, and avoid suppressions that accumulate without explanation.
A CI-friendly scripts set
{
"scripts": {
"typecheck": "tsc --noEmit",
"test": "vitest run",
"lint": "eslint .",
"check": "npm run typecheck && npm run lint && npm test"
}
}💡 The example uses Vitest and ESLint, but equivalent tools are fine. The important idea is that type checking is an explicit step, not assumed to happen because tests run.
Key Takeaways
- Type checking, tests, and linting have different purposes.
- Keep a dedicated type-check step in CI.
- Treat suppression comments as documented exceptions.
Knowledge Check
Which check most directly catches a value assigned to an incompatible TypeScript type?