ADR 0014: Enforce typed-rule performance budgets with hotspot-oriented instrumentation
- Status: Accepted
- Date: 2026-03-09
Contextā
Typed rules can incur significant cost from checker lookups, constrained type resolution, and rewrite-safety analysis. As rule coverage grows, these costs can stack in editor save cycles and CI lint runs.
The repository already includes benchmark fixtures and profiling guides, but contributor workflows need an explicit architectural decision tying semantic-rule expansion to performance budget discipline.
Decisionā
Adopt a performance-governance contract for typed rules:
- New semantic checks must be guarded by syntax prefilters where practical.
- Repeated semantic computations should use memoization/caching when AST identity is stable.
- Meaningful typed-rule expansions should be validated against benchmark/profiling workflows.
- Regressions beyond accepted budget thresholds require design-level remediation before merge.
Rationaleā
- Editor DX: lint-on-save latency must remain predictable.
- Scalability: guardrails prevent cumulative O(n²)-style drift in complex visitors.
- Operational clarity: contributors have explicit criteria for when to profile and optimize.
Consequencesā
- Contributors need to justify new checker-heavy logic with guard/caching strategy.
- Benchmark and performance diagnostics become part of typed-rule review, not optional extras.
- Some feature proposals may be deferred or re-scoped when they violate budget targets.
Revisit Triggersā
Re-evaluate if:
- ESLint execution model changes in ways that shift hotspot behavior (e.g., parallelized rule execution),
- TypeScript checker APIs gain lower-cost equivalents for key operations,
- or project policy changes to prioritize rule breadth over lint latency.