Anja Petry

HTML

Community Picks is a section on daily.dev where our community members share the most interesting and valuable content they've discovered online. From insightful articles to handy tools, every post is a gem curated by our dedicated coomunity. To contribute to Community Picks, you need to have at least 250 reputation points, ensuring that only active and trusted members can share their finds.

Community Picks

Migrating a 160,000-line production JavaScript codebase to TypeScript was challenging but beneficial for WorkMade, a seed-stage startup. Despite the complexities, including zero downtime and multiple environments, the migration improved developer experience, maintainability, and stability. Success was achieved through a strategic approach, including a separate migration branch, incremental typing, continuous integration validation, and extensive testing. Essential tools and extensions, such as ESLint with TypeScript support and Checkly for monitoring, played crucial roles.

Migrating 160,000 Lines of Production Banking JavaScript to TypeScript with Zero Downtime

The Challenge: Migrating at Scale Without Disruption

The Strategy: Maintaining a Separate Branch

Testing and Staging: Ensuring Zero Downtime

Results: Enhanced Developer Experience and Bug Fixes

Tools and Extensions That Made It Possible

production banking in javascript.

I wonder why not to migrate incrementally?
<ol>
<li>Introduce TypeScript, convert all .js files to .js files, add @ts-nocheck to the top of each file, and merge the changes.</li>
<li>Introduce a requirement: if a file is modified, @ts-nocheck must be removed and all errors fixed.</li>
<li>Keep track of the number of @ts-nocheck comments and set a specific goal: for example, agree that when there are 50 @ts-nocheck comments left, you will fix them all in a separate task</li>
</ol>

Worse thing in converting JS to TS is often practice I meet in legacy code - same function called with different sets of arguments, and if /then / else hell inside of the function to check what’s in type and return different result. I wonder always, why people not create separate functions for such cases? Usually after looking inside the code you meet so messy and untraceable logic, that you realize that nobody was brave enough, to refactor that shit.
I always tell: if typing some function / result / struct is difficult, then probably something is fundamentally wrong with approach to the problem.

Transitioning a massive JS codebase to TypeScript without downtime is no small feat! The methodology outlined here is a testament to careful engineering. But it makes me wonder: how do teams strike the perfect balance between making such incremental changes and keeping the velocity of new feature development?
Also, the long-term benefits of TypeScript are undeniable. But for massive projects like this, I imagine the investment in time and resources must be significant. Would love to hear how other teams manage these trade-offs or tackle similar migrations in a high-stakes environment. Have you faced something similar?