BT

New Early adopter or innovator? InfoQ has been working on some new features for you. Learn more

Moving from JavaScript to TypeScript at Slack

| by Sergio De Simone on Apr 17, 2017. Estimated reading time: 3 minutes |

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 any type is one of the strongest arguments for moving a code base into TypeScript. It allows you to slowly replace those any declarations 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.

Rate this Article

Adoption Stage
Style

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread
Community comments

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Discuss

Login to InfoQ to interact with what matters most to you.


Recover your password...

Follow

Follow your favorite topics and editors

Quick overview of most important highlights in the industry and on the site.

Like

More signal, less noise

Build your own feed by choosing topics you want to read about and editors you want to hear from.

Notifications

Stay up-to-date

Set up your notifications and don't miss out on content that matters to you

BT