How to Do a TypeScript Conversion

Airbnb converted many millions of lines gradually using automation and wrote about it:<p><a href="https:&#x2F;&#x2F;medium.com&#x2F;airbnb-engineering&#x2F;ts-migrate-a-tool-for-migrating-to-typescript-at-scale-cd23bfeb5cc" rel="nofollow noreferrer">https:&#x2F;&#x2F;medium.com&#x2F;airbnb-engineering&#x2F;ts-migrate-a-tool-for-...</a><p>And also open sourced the tooling:<p><a href="https:&#x2F;&#x2F;github.com&#x2F;airbnb&#x2F;ts-migrate">https:&#x2F;&#x2F;github.com&#x2F;airbnb&#x2F;ts-migrate</a>

Having done several Typescript migration on 100k+ line codebases, this rings entirely true for me.<p>An additional problem with doing partial migrations is that it leaves people in a position to just not fix the file they’re working on, since half converted files are the norm, and they have more important things to do.

I’m currently going through this at work and my experience even with smaller packages agrees with the author: After trying it the loose way and failing, I realised the best way to proceed is with maximum strictness from the start, converting the .js files to .ts in dependency order. When a file is converted from .js to .js, it’s almost guaranteed to be 100% converted. There are probably some edge cases where some refactoring necessitated by the conversion propagates to its already converted dependencies, but I would expect those to be minimal.

Bit of a shameless plug, but I wrote about how Etsy migrated to TypeScript a few years back. I agree with the author generally: TS strict mode is the way to go, and you may find yourself regretting the alternative, even if it sounds appealing. It takes a lot of work, but most of the effort ended up being:<p>1. writing types for the big, central libraries that everyone uses (and make them &quot;smart enough&quot; to infer as much as possible).<p>2. teaching everyone at the company a brand new language without them hating it, and without their team losing (much) velocity.<p><a href="https:&#x2F;&#x2F;codeascraft.com&#x2F;2021&#x2F;11&#x2F;08&#x2F;etsys-journey-to-typescript&#x2F;" rel="nofollow noreferrer">https:&#x2F;&#x2F;codeascraft.com&#x2F;2021&#x2F;11&#x2F;08&#x2F;etsys-journey-to-typescri...</a>

I don&#x27;t really like the idea of sprinking around &#x27;any&#x27; to silence noImplicitAny problems.<p>Either put in the correct type or leave it as is. Placing &#x27;any&#x27; in the code just fossilizes badness. Implicit any is just easier to accept, because when you finally have time to get serious you can disable it an write the correct types. You don&#x27;t have to hunt for &#x27;any&#x27; throughout the code.

I think ChatGPT makes a huge difference here.<p>I routinely ask it to convert javascript to typescript.<p>It does a great job for the most part in seconds, leaving me to clean up where it got it wrong, and then fix the bugs that typescript exposed.<p>Surely this makes the task easier?<p>The only trap to avoid is it takes a conscious decision to do no other factoring than the typescript conversion. Don’t start “just fixing this other little thing while I’m here”.

I forget where I learned this. But this follows my refactoring legacy code principal.<p>Your new code (typescript in this case) should never reference the old code. Old code is the only thing that knows about new code.<p>The reason being is if your new code ever knows about your old code, your new code will carry on old code forever. You can never escape.<p>But if only old code knows about new code. Your new code is perfectly clean.<p>For this typescript conversion problem the nice thing is you can configure typescript to allowJs and your existing code can import compiled typescript

Is there any automated tool that can add types? I have Playwright E2E tests – it seems reasonable that the type each variable is used as could be recorded and the code annotated with that.

The article only touches this: when converting to TypeScript, `any` is useful, but in the end you don&#x27;t want this type in your codebase - so don&#x27;t forget to use typescript-eslint [0] and turn on those no-unsafe-* rules which guard against `any` leaking into your code.<p>[0] <a href="https:&#x2F;&#x2F;github.com&#x2F;typescript-eslint&#x2F;typescript-eslint">https:&#x2F;&#x2F;github.com&#x2F;typescript-eslint&#x2F;typescript-eslint</a>

This seemed like the best approach, and the team I was last part of took it with reasonable positive results. One of the challenges however was less about actual module dependencies being converted before or after, but about conflict resolution when we&#x27;d end up needing to create and reconcile the same type across sibling leaves and coordinating that on the fly, especially while learning about the files we might not have written and only being able to reason about the logic at a high level before getting into the weeds of it.

I recently converted most of my team&#x27;s code alongside two coworkers. While I think it probably shortened the overall time, trying to split that work meant we stepped on each other&#x27;s toes a lot. Due to the usual time pressure and regression avoidance, we&#x27;ve ended up with more casting and non-null assertions than I&#x27;m comfortable with. Still I think it was worthwhile.