Slow and Steady: Converting Sentry’s Entire Frontend to TypeScript
Join the DZone community and get the full member experience.Join For Free
In this blog post, we share our process, techniques, challenges, and ultimately, what we learned along this journey.
Back in 2019, we were shipping more frontend bugs than was acceptable. After looking at the underlying causes of these incidents, it became clear that many of these bugs could have been prevented by static analysis and type checking.
During that year’s Hackweek event, Lyn Nagara, Alberto Leal, and Daniel Griesser pitched introducing TypeScript to the Sentry frontend. This team bootstrapped the TypeScript compiler to our build process as well as converted a few non-trivial views — and their related components — to TypeScript.
Hackweek is an event that takes place once a year, giving all Sentry employees the opportunity to set aside their usual work to focus solely on innovative projects and ideas. Hackweek has given birth to numerous applications and tools that are now important parts of our product, like the recently launched Dark Mode project.
After considering the presentation, we felt Typescript was a strong fit for Sentry because:
- Several classes of bugs could be detected — and eliminated — during compilation.
- We could improve the developer experience through editor integrations such as auto-completion, faster code navigation, and inline compiler feedback.
- We could reduce the need for API documentation, as type annotations help produce self-describing code.
- TypeScript has an active community with a clear and maintained development roadmap in addition to rapid releases.
- Many of the libraries we use (including React) already have type definitions available.
- TypeScript can be adopted incrementally. That meant we can start writing new code with TypeScript and incrementally convert over time.
There were some potential drawbacks of adopting TypeScript, though:
- It’s a large time investment. Our frontend code is non-trivial in scope, so it would take significant effort to convert it. That complexity meant additional build time.
- We would need to educate the frontend team in TypeScript and support them as they learned.
Maturing the Prototype
Shortly after Hackweek, excitement was high and a more formal proposal was brought to our Frontend Technical Steering Committee (TSC). This group meets every two weeks to guide our front-end architecture. While TypeScript wasn’t among the “winning” projects for Hackweek, we were confident that it would be a worthwhile investment that would ultimately pay off in the long run.
We broke our high-level strategy into several phases:
- Educate. In this phase, we needed to let people know that TypeScript was coming, and provide the right learning resources to help folks onboard.
- Conversion. In this phase, all new work would be done in TypeScript, giving us a finite number of files to convert. Then it is “just work”™️.
Our most controversial decision was agreeing to not undergo any other major refactors until the codebase was converted 100% to TypeScript. This meant we would not take on other quality-of-life improvements — things like upgrading our state-management library or introducing React hooks — until the TypeScript conversion was complete.
Early on, we recognized that the broader development team at Sentry would need additional resources and materials to learn TypeScript. To help folks who were new to TypeScript, we shared a list of introductory articles and resources for configuring various editors.
Additionally, members of the TSC took the time to review code and help educate those folks eager to learn TypeScript. Having this support system in place helped create more TypeScript “believers” who would, over time, write new code in TypeScript.
Published at DZone with permission of Mark Story. See the original article here.
Opinions expressed by DZone contributors are their own.