Type-Aware Linting Without Surprises

Type-aware rules are powerful, but they become noisy fast when parser-service assumptions are unclear.

The goal is not “run typed rules everywhere immediately.” The goal is predictable behavior under real project conditions.

The contract we want

A healthy typed-rule setup has three explicit outcomes:

1. Typed path available: semantic checks run with parser services + checker.
2. Optional typed path unavailable: semantic branch is skipped safely.
3. Required typed path unavailable: fail fast with a clear configuration signal.

That split keeps failures actionable and prevents silent drift.

Why guard-first design matters

In large codebases, parser-service availability is not uniform:

• different tsconfig scopes
• mixed package boundaries
• generated or excluded files

Guard-first execution avoids brittle behavior by making typed entry conditions explicit.

Rollout pattern that works

• Start in one folder/package.
• Measure with --stats before and after enabling typed checks.
• Promote from warn to error once baseline noise is gone.
• Expand scope only when performance and diagnostics stay stable.

What to track

• typed-rule error rate tied to config gaps
• lint runtime deltas after enabling typed presets
• rule-level hotspots that call checker APIs most often

If those stay stable, typed linting remains a quality upgrade instead of a workflow tax.

Related docs

• Typed service path inventory
• Typed rule semantic analysis flow
• Type-aware linting readiness guide