TypeScript Static Code Analysis: A Developer's Guide

TypeScript's Built-in Static Analysis

TypeScript's compiler (tsc) is itself a static analysis engine. Type checking — the compiler's core function — is a form of static analysis that catches type mismatches, null access on nullable values, incorrect function signatures, and other errors without executing code. This makes TypeScript one of the best languages for catching issues statically.

But the TypeScript compiler is not a complete static analysis solution. It focuses on type correctness and leaves code quality, security analysis, and style enforcement to additional tooling.

Key TypeScript Static Analysis Tools

TypeScript Compiler (tsc)

Run `tsc --noEmit` in CI to type-check without producing output files. Key strict flags to enable:

• --strict (enables all strict flags)
• --noImplicitAny (require explicit types, no implicit any)
• --strictNullChecks (null and undefined are not assignable to other types)
• --noUncheckedIndexedAccess (array/object access returns T | undefined)
• --exactOptionalPropertyTypes (distinguish undefined from absent)

typescript-eslint

The standard way to run ESLint on TypeScript code. Provides type-aware lint rules that use the TypeScript type checker to catch issues ESLint alone cannot see: unsafe any usage, incorrect generic usage, type assertion abuse.

ESLint with type-aware rules

typescript-eslint's recommended-type-checked config enables rules that require full type information. These are slower than standard lint rules (because they invoke the type checker) but catch an additional class of issues: calling methods that don't exist on a type, returning the wrong type, and misusing async/await.

Knip

Detects unused exports, files, and dependencies in TypeScript projects. As TypeScript projects grow, unused code accumulates — exported functions that are never imported, type definitions that are never used. Knip surfaces this systematically.

Common Issues Detected

• Type mismatches and assignment compatibility errors
• Null and undefined access without guards
• Any type usage that bypasses type safety
• Unsafe type assertions (as unknown as SomeType)
• Incorrect generic constraints and variance
• Async function return type mismatches
• Unused variables, parameters, and exports
• Missing exhaustiveness checks in discriminated unions
• Security: unsafe eval, injection-prone patterns, prototype pollution

Running Static Analysis

A production TypeScript CI analysis pipeline:

1. Type-check: tsc --noEmit --strict
2. Lint: eslint . --ext .ts,.tsx --report-unused-disable-directives
3. Detect unused code: knip
4. Security scan: semgrep --config=p/typescript (or custom rules)
5. Block merge on: type errors, error-level lint findings, and high-severity security findings

tsconfig.json Best Practices

The TypeScript compiler configuration determines what is checked. For production code:

• Enable "strict": true — this is the minimum acceptable configuration
• Add noUncheckedIndexedAccess: true — catches array out-of-bounds and index signature issues
• Use separate tsconfig for tests — allow looser rules in test files without polluting production checks
• Avoid skipLibCheck: true in production — it suppresses errors in node_modules type definitions that can indicate real issues

Connection to Autonomous Code Governance

TypeScript's type system makes autonomous remediation more reliable: the type checker verifies that generated fixes are type-correct before they are surfaced. Hydra leverages TypeScript's static guarantees to ensure remediation PRs pass type checking, ESLint, and security scans as part of the fix verification pipeline — not just behavioral tests.