Inside Figma: a case study on strict null checks | Figma Blog
Figma enabled TypeScript’s `strictNullChecks` incrementally to eliminate null-related bugs without halting product development. The migration addressed more than 4,000 compiler errors across roughly 1,162 files and helped prevent a class of production incidents. Figma concluded that a progressive, allowlist-based rollout was more practical than either stopping all development or fixing errors indefinitely without enforcing the setting. ## What Strict Null Checks Provide - Without `strictNullChecks`, ordinary types such as `Vector` may also contain `null`, making unsafe property access possible. - With the option enabled: - Non-nullable types cannot be assigned `null`. - Nullable values must be explicitly declared, such as `Vector | null`. - TypeScript uses control-flow analysis to narrow types after null checks. - This prevents errors such as accessing `.name` on `undefined`. - The type system also documents important assumptions, such as whether data has been loaded, making code easier to maintain. - Figma’s historical incident data showed that strict null checks could have caught several high-severity production issues before release. ## Why the Migration Was Difficult - Figma adopted TypeScript before strict null checks existed and had accumulated code that did not satisfy the newer rules. - Enabling the option immediately produced more than 4,000 errors across approximately 1,162 frontend TypeScript files. - Fixing one error could expose additional errors. - Meanwhile, the codebase continued growing—from 376,000 to 464,000 lines during the migration—making a strategy that allowed progress to reverse particularly risky. ## Alternatives Figma Rejected ### Stop-the-World Migration - All engineers could have paused product work to fix the type errors. - Figma rejected this because: - The work was only partly parallelizable. - Product development was strategically important. - Coordinating a company-wide effort becomes increasingly difficult as organizations grow. ### Whack-a-Mole Error Fixing - Teams could fix strict-null errors over time while enforcing the checks only in CI. - This minimizes disruption but permits new code to introduce additional errors. - The approach is viable only if errors are fixed faster than they are added. - Figma found a continually moving progress target unattractive, especially given rapid codebase growth. ## Progressive Allowlisting - Figma chose to strict-null-check one file at a time by adding successfully migrated files to an allowlist. - The approach was inspired by the VS Code team’s strict-null migration. - The build compiles the codebase twice: - Once with strict null checks disabled for the general codebase. - Once with strict null checks enabled for files on the allowlist. - This allowed teams to migrate files incrementally while continuing normal development elsewhere. Figma’s experience recommends progressive enforcement for large, actively developed TypeScript codebases: isolate compliant files, enforce the stricter rules there, and expand the allowlist until the entire codebase is migrated.
Read original(opens in new tab)