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.