Static Analysis

Automationintermediateaka Static Code Analysis

// Definition

Examining code for problems without running it — linters (ESLint), type-checkers (`tsc`), formatters, and security scanners (SAST) that read the source and flag bugs, style violations, type errors, or vulnerabilities. It's the cheapest, earliest quality gate: feedback in seconds on every file, before a single test executes. The counterpart to dynamic analysis, which finds issues by running the program.

// Why it matters

Static analysis catches a whole class of defects — undefined variables, unhandled promises, type mismatches, known-insecure patterns — for almost no cost and with zero flakiness, which makes it the ideal first gate in CI. QA cares because every bug a linter or type-checker catches is one your tests don't have to (and a fast, deterministic signal beats a slow, sometimes-flaky one). It also keeps the test code itself honest.

// How to test

// Static gates run before the test suite, on every commit/PR:
//   tsc --noEmit        → type errors, no build
//   eslint .            → bug-prone patterns, unused vars, bad awaits
//   (SAST scanner)      → known-insecure code patterns
// Wire them as required CI checks so nothing merges on a static failure:
//   "scripts": { "lint": "eslint .", "typecheck": "tsc --noEmit" }
// A clean static pass is the precondition for spending time on dynamic tests.

// Common mistakes

  • Treating lint/type errors as warnings instead of merge-blocking gates
  • Running static analysis locally but not in CI, so it drifts and rots
  • Over-suppressing rules (blanket eslint-disable) until the signal is meaningless

// Related terms