Proposal: switch to TypeScript


This post is mainly directed at @Leftmost_Cat, @mr_monkey, @arthelon2 and @shivamt, all of whom I think have written some code for BookBrainz over the past year (but others are welcome to join in!)

I’d like us to decide whether to continue using Flow for type checking, or whether we should switch to TypeScript. Initially, when choosing a type checking system for BookBrainz, it seemed that Flow was the least intrusive of the two, and that we could gradually migrate our code to use it, while TypeScript seemed to be the better choice for new projects.

Because of this Flow was picked and integrated into a few of our repositories (mainly the site). I’d estimate that about 30 files have some meaningful type annotation with Flow.

However, over the past few months, I’ve become increasingly disappointed with Flow. When running it consumes a huge amount of system memory, and seems to have some memory leak which result in certain code structures forcing me to terminate the processes. It’s also quite slow, and lacks good integration with IDEs. In contrast, TypeScript is extremely well integrated into VSCode, faster and supports a variety of features (autocomplete and automatic refactoring) that Flow doesn’t. For more info, see:

According to it’s quite easy to convert from Flow to TypeScript, and an automatic tool actually exists to do it (haven’t tried it though): . I’d like to propose that we start a branch in bookbrainz-site and start migrating a few of our Flow annotated files over.



I think there are two important questions to answer at this juncture:

  1. Will this increase velocity?
  2. If we don’t take this path, how hard will it be to come back to it in future?

I can’t answer 2, as I’m not familiar enough with the difficulties it could present. As for 1, though, I have strong doubts that it will. Using TypeScript might give us a bit of a boost, but at the cost of additional churn and time spent on yak shaving. Ultimately, it may be a good idea, but if we can put it off, I’d much rather do so.


Just as a disclaimer, I’ve worked on one large JavaScript project where we eventually switched to using TypeScript.

To answer the second point from @Leftmost_Cat, TypeScript is something that can be gradually introduced into the codebase so I don’t think there’s an immediate need to convert. The TypeScript compiler is interoperable with JavaScript files and can even performs some basic error checks.

Having used both Flow and TypeScript before, TypeScript editor integrations are a lot more powerful and the compiler seems to be able to catch more errors and provide better completions. That said, the benefits of TypeScript can only really shine once a decent portion of the codebase is converted and there is some maintenance cost in creating/updating types and dealing with the “strictness” of the compiler.

Like @Leftmost_Cat pointed out, I’m also not sure if the complexity of the codebase is at the point where using TypeScript would significantly speed up development. Better error-checking is nice to have though.


Worth keeping in mind that MBS uses Flow, if we want to try to keep a standard of some sorts among the two projects. Not that it’s necessary either, I guess, but IMO whatever makes it easier for people to contribute to both should be a good thing.


@Bitmap - what are your thoughts on this topic?

@Leftmost_Cat - you’re right that this won’t lead to a direct increase in velocity. But it also won’t cost much time to switch over - maybe 3-6 hours. I think it makes sense to do this sooner rather than later when we have more Flow-annotated code.

@reosarevok - good point. However, if we were to share code, we’d probably split it into a separate JS package, and it’s possible to create a TypeScript side-file alongside a Flow side-file to provide type information for both systems. But I’d like to hear what @bitmap has to say first.


@LordSputnik Well, I was first looking into adding types to MB sometime in 2016. From what I remember, both TS and Flow had major issues, but Flow had much better type inference (you barely had to add any types and still got good checking), and TS didn’t have what is now strictNullChecks yet, which was kind of a dealbreaker; null and undefined dereference errors were probably one of the most common bugs we’d see.

Flow was easier to integrate. Our build system was already set up and working well using Babel. TS has its own transpiler, and I didn’t want to go through all our Babel plugins and figure out what would break.

I imagine there were other small reasons which I don’t remember.

I’ve kept up with TS development out of interest and it’s certainly moved at a much faster pace than Flow and is better in some ways. You wouldn’t be wrong to go with TS. Flow is steadily improving too, though, and I don’t think it’s a good use of MB development time to switch right now. I also know for a fact that for every issue I currently have with Flow, I’ll find a different one in TS. :slight_smile: Nominal types are one example of a feature I’d hate to lose.


I’ve only extensively used TS so I can’t compare properly. The article you posted helps.

In my opinion, unless you’ve identified a specific blocker that would require the change or that Flow is stopping users from participating, I’d rather see development efforts be directed towards the functionality of the website in priority.