Switching from JavaScript to TypeScript at Slack has been challenging but dramatically beneficial, writes Slack desktop engineer Felix Rieseberg.
The Slack team decided to move to TypeScript to make it easier to manage their large JavaScript codebase and after giving up on the use of JSDoc to document function signatures, describe proper usage, etc. In particular, Rieseberg says, it is hard to follow the JSON approach on an existing codebase, since it requires strict discipline when modifying code and because it is not always easy to know what the expected type is, e.g., what a promise resolves with.
One of the reasons why the Slack team chose TypeScript is its being a superset of JavaScript, making it possible to adopt it without changing a single line of code and then gradually enabling its code analysis features and including the type definitions available for many popular packages. Over time, they reached the point of enabling advanced compiler options, such as --noImplicitAny to prevent the compiler from inferring an any type. Overall, says Rieseberg, it took about six months to annotate most of the desktop app code base. In the process, the compiler uncovered many bugs and sped up development thanks to the advanced editing features that it makes possible, e.g. auto-completion.
InfoQ has spoken with Rieseberg to learn more about his experience.
You describe a gradual approach to enabling TypeScript’s compiler options. Could you provide more details on what options can be enabled from the very early stages, and which ones turned out to require more work on the existing code?
Felix Rieseberg: I believe that the
anytype is one of the strongest arguments for moving a code base into TypeScript. It allows you to slowly replace thoseanydeclarations with more specific types and interfaces over time. As the use of types grows, one will sooner or later enjoy the abstractions offered by intersection and union types, which can be daunting to developers new to type systems. In my personal view, a gradual adoption of TypeScript is mostly powered by its ability to accept existing JavaScript – TypeScript will attempt to understand your code and support your development as much as possible, but it will not refuse to be of assistance if you do not have the time to port your whole code base over in one go.
Moving from a dynamically-typed to a strictly-typed language sometimes leads to the opening up of opportunities to re-design things. Have you had any such experience at Slack?
Rieseberg: Our conversion to TypeScript was mostly done by our developer OJ Kwon, who started the conversion quickly after joining our team. He found many opportunities to improve our existing code base. In particular, porting over to TypeScript helped us understand the flow of data inside our architecture a bit better, but to a bigger extent, revisiting existing code is always an invitation to rethink the taken approach.
At the language level, which of its features helped you to build an expressive type-system?
Rieseberg: I particularly enjoy declaration merging, allowing us to reuse existing types and declarations to express the objects we’re dealing with. Also, while certainly less interesting, string literal types can be found everywhere in our codebase.
One of TypeScript’s strength that you highlight is its being a superset of JavaScript. On the other hand, being so means you cannot be really sure about anything that you get from the pure-JavaScript layer of your app. What has been your approach to this? Was it in any way problematic?
Rieseberg: It's important to point out that TypeScript comes with a sidekick called Salsa - a development server that provides a TypeScript-like experience while working with JavaScript. It's the engine that powers Visual Studio Code's understanding of your JavaScript. We fared well with a combination of TypeScript, declaration files, and usage of Salsa during development. I personally enjoy TypeScript's approach with definition files.
