Trying out TypeScript — Part 1

Justin Krup
Jul 10, 2019 · 5 min read
Image for post
Image for post
Image for post
Image for post
TypeScript (left) vs JavaScript (right)

At Priceline we’re maintaining thousands of lines of codes for the front-end, across several dozen repositories. Because of this, it’s important that any major undertaking, such as using TypeScript, has a clear path to not being disruptive.

Why use TypeScript?

By using TypeScript we can get powerful intelligent autocompletion.

Image for post
Image for post
By defining our object types we get intelligent autocompletion on our objects.
Image for post
Image for post
Airbnb famously claimed that 38% of bugs were preventable with TypeScript

Airbnb recently stated that 38% of bugs were preventable with TypeScript.

For example, when converting one file to TypeScript, we got an error message on a line of code that looked like this:

someArry.sort((a, b) => a > b)

The issue is Array.prototype.sort should be given a function that returns a number, not a boolean, and thus will not be sorted properly in many cases. Since JavaScript is not strongly typed, it treats false as a 0 and true as a 1, so no error is even thrown, but buggy sorting logic can persist in the application.

Hesitations against using TS

So given these great reasons to use TS, why isn’t everyone already on it?

Well, there are a few reasons:

There is some amount of overhead involved in the build process. Almost every application these days already has a build pipeline, but if you were working without one (i.e. writing vanilla JS that runs directly in the browser or via node) then you’d need to start using build tools. Even if you already have a build pipeline, you would need to reconfigure it, which can sometimes mean a day or two of chasing down weird issues.

It’s a “new” language to learn. If you’re not used to it, the syntax can certainly be off-putting. Seeing interface HydratedWindow extends window { ... } or function (user : User, action : ActionEnum) can be a bit off putting for some developers who are not familiar with it. In particular, programmers with little experience using strongly typed languages will struggle with this syntax.

Both of these concerns are addressed below.

How We Started Using TypeScript

At Priceline, we went about introducing TypeScript through a very cautious approach. We actually began not by using TypeScript directly, but rather by getting many of the benefits of its language-server via comments in JavaScript.

The TypeScript Compiler tsc and typescript-language-server can actually read JavaScript and JSDoc comments to provide all of the benefits of TypeScript! There’s a great article here that covers this at length, but essentially you can just write comments following a particular syntax around your existing JS code and set a //@ts-check at the very top of your file and in VSCode (or any editor that can integrate with the typescript-language-server) you’ll see typechecking, autocompletion, linting, etc.

Image for post
Image for post
A vanilla JavaScript file with JSDoc syntax, providing strict typing linter errors in Vim.

By following this methodology, there is no additional compile step, since all that is actually being added is comments. Thus we could keep our existing build process completely untouched.

This has the added benefit of encouraging people to start writing documentation. Since you’re already adding all of these multi-block comments, it’s easy to start including things like descriptions rather than just types.

As we worked on existing tasks, we would occasionally drop in a few JSDoc code blocks to get types just for those functions, and just “type” as we go, rather than halting our work to expend effort to fully re-write an entire repo. Some tricks we used would be to temporarily turn on strict: true in our linter’s settings to see anywhere we are using an implicit any type and then resolve those within a single file.

Important to recommend that you not bite off more than you can chew. In our GraphQL projects, we’re often dealing with very large nested Objects. We don’t want to just use type Object as that’s hardly any better than any, but on the other hand it can take hours to fully type out these objects. So we’ve decided to often follow JS’s pattern of “shallow copying”.

If we’re working with some massive object we’ll usually just declare the top level shape of it, and any children we are using, but just use Object type for anything lower level. For example:

* @typedef {Object} APIResponse
* @property {Object} details
* @property {string} statusCode

Rather than going into all the details of the details object right away, on our first pass we’re simply working on getting all the highest level objects defined.

Once we got a taste of some of the benefits of TypeScript by using JSDocs, we felt ready to bite the bullet and try out full-blown TypeScript. Since we were already using Babel, the build system configurations were fairly easy. We just had to upgrade to Babel 7, and then it was straightforward to just use the babel-preset-typescript plugin, and tell Webpack to include .ts files.

Since Typescript is a superset of JavaScript, whenever we feel like adding some types, we can just rename an existing .js file to .ts and begin to add typing.


We’re really just getting started with using TypeScript here, but Priceline is excited for what TypeScript has to offer for our engineering process and we look forward to sharing more in the future.

If you’ve been hearing about TypeScript and are unsure of how to start benefiting from it, hopefully this has provided some insight on how you could apply it either in your existing applications, or in your next one.

Excited by what we’re doing at Priceline? We’d love to have you apply here.

priceline labs

Learn how Priceline builds applications that help people…

Medium is an open platform where 170 million readers come to find insightful and dynamic thinking. Here, expert and undiscovered voices alike dive into the heart of any topic and bring new ideas to the surface. Learn more

Follow the writers, publications, and topics that matter to you, and you’ll see them on your homepage and in your inbox. Explore

If you have a story to tell, knowledge to share, or a perspective to offer — welcome home. It’s easy and free to post your thinking on any topic. Write on Medium

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store