How Dashlane Improved Code Quality with TypeScript

Producing quality code is one of our main objectives at Dashlane. We’re TDD aficionados, and always keep a close eye on our unit test coverage. Every change in the codebase must result in a pull request to be reviewed by team members before it can be merged. This is why, when we got started 6 months ago on a new large JavaScript project, we decided to go with TypeScript in order to keep improving our code quality, we felt like we needed the additional safety net of a static type system. Here’s three ways  TypeScript has improved our code quality thus far:

We Catch Errors Early

Programmers are human, and will make mistakes when writing code. What matters is being able to catch these mistakes early on, ideally long before the code is deployed to the end user. TypeScript has one big advantage over vanilla ES5/ES6: it allows the programmer to catch a lot of errors at compile time, instead of allowing them to happen at runtime. Take the example of .toUpperCase() being called on a number because the variable initialization has been changed somewhere in the program. This would throw a TypeError at runtime in vanilla JavaScript, all without a single complain from the interpreter when you start your program, since it is still valid JS code. In TypeScript, your program is statically checked for correctness before it runs, and you will get a compilation error stating that  number has no toUpperCase() method. The shortened feedback loop introduced by the static type system is invaluable in improving stability in your application: nobody wants their client-side or server app to crash at runtime!

Easier Refactoring

Every big project requires refactors as the project progresses, to make the integration of a new feature easier, introduce some changes to the data model of the program, or simply clean up old code. Big refactors in the codebase are much easier when using TypeScript, because the compiler will give you an immediate overview of what your changes have broken. Most importantly, it will do so across the whole codebase. Say you change a function signature – the compiler will output an error for every call site, allowing you to fix all of them before pushing your changes out for review. Since we started using TypeScript, we’ve found that we were much more inclined to tackling big refactors, since we can rely on the compiler to do a lot of the grunt work for us. This means that we keep our codebases evolving continually, and are much better at avoiding code rot.

Improved Team Collaboration

Our JavaScript projects typically involve several team members, and sometimes several teams. TypeScript makes collaboration on large projects very smooth. You can rely on the compiler to make sure that the code that your changes do not break your teammates’ code. Using code produced by other people is also much easier. For example, we will typically define an interface for our options objects: they’re easy to read, provide information on types and optional parameters which will be checked at compile-time, and are more resilient than if we were to describe the options structure in a comment, which would get outdated quickly.

We also created the following presentation to further explain our decision to use TypeScript for our current and upcoming JavaScript projects.

Does your development team currently use TypeScript? Tell us about it! I’d love to know how and why your team uses TypeScript in the comments section below.

We’re also looking for passionate JavaScript developers to work on this project with us! Apply to join the Dashlane team today!