--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 those
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.