TL;DR
Twitch’s core engineering team addressed invisible exceptions in a million-line TypeScript monolith by treating lint rule violations as tracked artifacts. They ran ESLint while ignoring in-file disables, captured a repository-level snapshot of rule/file pairs, and used CODEOWNERS to route changes to the core team for review.
What happened
As multiple teams worked in a single, large TypeScript codebase, small, often accidental workarounds accumulated: editor integrations adding eslint-disable comments, copied code carrying exceptions, refactors moving code without re-evaluating rules, and temporary TypeScript or test escapes. These patterns made it hard for the central standards team to distinguish deliberate tradeoffs from unchecked drift. Instead of policing developers or forcing big refactors, the team converted rule exceptions into reviewable artifacts. They ran ESLint with a flag that treated every eslint-disable as if it were absent, captured the resulting violations into a single snapshot file at the repo root, and removed line numbers so entries mapped only a rule to a file. That snapshot was owned by the core team via CODEOWNERS. Any addition, rename, or relocation that changed the snapshot generated a diff that pulled the core team into review, letting authors explain context and maintainers decide whether to adjust or uphold rules.
Why it matters
- Makes exceptions visible and reviewable rather than silently accumulating in source files.
- Enables standards to evolve incrementally without blocking developer velocity.
- Creates a clear feedback loop between authors and standards maintainers.
- Turns implicit workarounds into explicit conversations that surface architectural pressure points.
Key facts
- The approach was applied to a monolithic TypeScript codebase of roughly one million lines.
- About 300 developers were shipping code in the shared repository.
- Common accidental bypasses included eslint-disable insertions, copied exceptions, refactor moves, and temporary type/test escapes.
- They ran ESLint with a flag that ignored eslint-disable comments to reveal all potential violations.
- Output was captured into a snapshot file at the repository root and line numbers were removed so entries mapped only rule-to-file.
- The snapshot file was assigned to the core team via CODEOWNERS so diffs routed to them for review.
- File renames or new violations in existing files produced snapshot diffs that triggered a review cycle.
- The TypeScript team engaged with Twitch engineers to help use the language more effectively.
What to watch next
- Follow-up engineering posts from the Twitch team detailing implementation and lessons learned (confirmed in the source).
- Whether other large codebases adopt lint-snapshot or similar snapshot-based ownership patterns (not confirmed in the source).
- Integration of snapshot review workflows into CI and modern developer tooling to reduce friction (not confirmed in the source).
Quick glossary
- ESLint: A code analysis tool that finds and fixes problems in JavaScript and TypeScript code according to configurable rules.
- eslint-disable: An inline comment directive that suppresses ESLint warnings or errors for a specific line or block of code.
- CODEOWNERS: A repository-level mechanism to specify which teams or individuals are responsible for specific files, often used to auto-request reviews.
- Lint snapshot: A recorded list of lint rule violations (typically reduced to rule and file pairings) stored as a repo artifact to track and review exceptions over time.
- Monolith: A single, large codebase where many teams collaborate and ship code, as opposed to a collection of independently deployed services.
Reader FAQ
Was this an indictment of TypeScript?
No. The engineering note explicitly states the issue was organizational coordination at scale; the TypeScript team engaged with Twitch to help use the language better.
Did the team block developers or force wide refactors?
No. The team wanted to avoid blocking development or requiring large refactors, preferring incremental evolution and visible exceptions.
How did the snapshot avoid churn from edits and refactoring?
Line numbers were stripped from the snapshot so entries mapped only a rule to a file, reducing churn from code edits while still surfacing renames or relocations.
Is this approach available as an off-the-shelf tool?
not confirmed in the source
How Twitch Tamed a Million Lines of TypeScript December 21, 2025 At Twitch, my team’s charter was to define and maintain core engineering standards: performance constraints, architectural patterns, TypeScript usage,…
Sources
- How Twitch tamed a million lines of TypeScript
- Moving off of TypeScript
- Twitch State of Engineering 2023
- Entertainment as Code: Finale
Related posts
- Observability’s Past, Present, and Future: Origins, Failures, and Outlook
- How fast can text chunking get? Inside memchunk’s ultra-fast approach
- Calibrating My Turtle: One User’s Ongoing Tension with Coding Agents