Porting 30K lines of code from Flow to TypeScript

Last updated 215 days ago by David Gomes

typescript

We recently ported MemSQL Studio's 30 thousand lines of JavaScript from using Flow to TypeScript. In this article, I describe why we ported our codebase, how it took place and how it has been working out for us.


Disclaimer: my goal with this blog post is not to condemn Flow or usage of Flow. I highly admire the project, and I think that there is enough space in the JavaScript community for both type checkers. At the end of the day, each team should study all their options and pick what's best for them. I sincerely hope this article helps you with that choice.


Let's start by setting some context. At MemSQL, we are big fans of statically and strongly typing our JavaScript code in order to avoid common issues with dynamic and weak typing such as:

  1. Runtime type errors due to different parts of the code not agreeing on implicit type contracts.
  2. Too much time spent writing tests for trivial things such as parameter type checking (runtime type checking also increases bundle size).
  3. Lacking editor/IDE integration, because, without static types, it's much harder to get jump-to-definition, mechanical refactoring and other features.
  4. Being able to write code around data models, which means that we can design our data types first and then our code will basically just "write itself".

These are just some of the advantages of static typing, I describe a few more in a recent blog post about Flow.

In early 2016, we started using tcomb to ensure some runtime type safety in one of our internal JavaScript projects (disclaimer: I was not a part of that project). While runtime type checking is sometimes useful, it doesn't doesn't even begin to scratch the power of static typing[1]. With that in mind, we decided to start using Flow for another project we started in 2016. At the time, Flow was a great choice because:

  • Backed by Facebook which has done an amazing job at growing React and the React community (they also develop React using Flow).
  • We didn't have to buy into an entirely new ecosystem of JavaScript development. Dropping Babel for tsc (TypeScript compiler) was scary because it wouldn't give us the flexibility to switch to Flow or another type checker in the future (obviously this has changed since then).
  • We didn't have to type our entire codebase (we wanted to get a feel for statically typed JavaScript before we went all-in), but rather we could just type a subset of the files. Note that both Flow and TypeScript allow you to do this nowadays.
  • TypeScript (at the time) was lacking some basic features that Flow already supported such as lookup types, generic parameter defaults and others.

When we started working on MemSQL Studio in late 2017, we set out to achieve full type coverage across the entire application (all of it is written in JavaScript and both the frontend and backend run inside the browser). We decided to use Flow as that's what we had been successfully using in the past.

Read full Article