How We Migrated over 200K Lines of Code to TypeScript in 2 Days


CAT Tool

  • Codebase created over 2 years ago (legacy code). People who architected and wrote a big part of the code don’t work here anymore.
  • Still a lot of feature requests.
  • More than 1300 files.
  • Over 230K lines of code.
  • Has Flow already but not everything was typed with Flow and Flow kind of sucks.

Motivation for Migrating to TypeScript

The major thrust to migrate the CAT Tool to TypeScript was Tech debt.

How to Migrate?

Originally wanted to incrementally Migrate the CAT Tool to TypeScript.


Doing the migration in a Hackathon makes sense for us because everyone who participated in the Hackathon had previous experience migrating our other codebases to TypeScript and had experience working with the CAT Tool.


We created WIP PRs for things we are currently working on so they are saved remotely. Resolving merge conflict will not be trivial.

The Hackathon

The goal of the Hackathon was to migrate the codebase to TypeScript without making any changes to the source code (unless trivial or absolutely necessary).

  • Non-existed css classes were used in React component. Those css classes did not exist in any of the style sheets so the solution was to delete them from the code.


We started the migration with over 4000 errors. At the end of the hackathon, we had fewer than 700 errors.

Challenges and Lessons Learned

There were some hurdles and issues during and after the migration.


Although the codebase was previously set up with Flow, not all files were properly typed. Some files were not typed at all. Flow is also less strict about typing than TypeScript. We ended up having to cast a lot of things to any.

Test Files

Most of our test files were not typed at all and contained a lot of boilerplate. We decided to exclude the specs from ts and lint for now because it’d take too long to refactor/add types to the specs because they don’t use global mocks.

PR review and version control

We had to change many files from .js to .ts and we want to do it without losing commit history. Because we were committing a lot of files at once, git gets confused about the file renaming and thinks that the js files were deleted and the ts files are new.

After Migration

Celebrate With Whisky

… But not before fixing a regression introduced by the migration

A critical bug appeared after the migration but it was quickly fixed.

  • Did not have sufficient automated unit test coverage
  • Did not perform a manual regression test thoroughly before merging to master

Followup Tasks

It’s not possible to perfectly migrate a codebase of this size in a few days or weeks. There were a lot of “hacks” (e.g., type-casting to any and excluding files from linting and ts check) we used to complete the initial migration. We created follow-up tasks to address these.

New York-based Software engineer. Currently at OkCupid. My website and blog:

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store