Lint

Linting in CI turns repeatable code-quality rules into an objective merge gate. Depending on the toolchain, it can cover imports, React hooks, accessibility, dead code, suspicious patterns, and integration with formatters.

| Layer | Typical tool | |-------|--------------| | Formatting | Prettier, Biome format | | Semantic lint | ESLint, Biome lint | | Type-aware lint | `typescript-eslint` with `project` |

					{
  "scripts": {
    "lint": "eslint . --max-warnings 0",
    "format:check": "prettier --check ."
  }
}
				

Strong pipelines run formatting and semantic lint as separate steps so failures are actionable. CI should be the authority for mechanical checks—local hooks are convenience, not the only gate.

On interviews: formatter versus semantic lint split, when type-aware lint is worth the cost, `--max-warnings 0` in CI, and keeping rule failures readable.

Common pitfalls: a noisy lint gate trains teams to bypass it; expensive type-aware lint on every file without caching; duplicating Prettier rules inside ESLint.

The trade-off is thoroughness versus feedback latency and developer tolerance for rule noise.

Checklist:

• Keep rules useful and actionable.
• Run formatting separately or consistently.
• Make CI authoritative for mechanical checks.
• Measure and cache slow lint paths.