Hi friends! It's me, Daniel.
If you know me IRL, you've probably heard me blather at length about something JavaScript related. My first professional programming job was almost all Vanilla JavaScript so I've loved JS for a long time. Unlike some folks, I find its quirks and eccentricities endearing. Prototypal inheritance is a bit wacky at first, but it's actually pretty straightforward for day-to-day needs. I've seen a lot of fads come and go (looking at you Coffeescript). That said, it took me a long time to get on the Typescript train. But look, now that I'm here? I am ALL IN.
I love Typescript. You get to set clearly understandable contracts for your data-structures, functions, and classes then enforce them at compile time. That means if somebody misuses something, or some contract/interface changes, it gets caught before going to prod and hurting your users. It's code that explains how it's supposed to be used. What's not to love about that? I was already thinking about JS this way, why not add a layer to explain my thoughts? This really shines for teams or cross-functionality, but it's also great for future-me (after I've slept and forgotten everything).
We use Typescript at my Day Job™ but it hasn't always been this way. I work in an application that is mumble-mumble years old with many generations of code - from the days of class-based React with Redux+Thunks to more modern React Hooks-based functional components. It's like digging through rocky sediment layers to uncover the historical whys-and-hows. Everything new is written in Typescript and that feels great - but it didn't help when we had to dig deeper into older features (or *gasp* clean up debt). As we realized the joy of using our new components (and the pain of using the old ones), I wanted to get there faster. I wanted to live in the future, not the past.
Enter AirBnB's amazingly handy tool, ts-migrate.
I wanted to get there faster. I wanted to live in the future, not the past.
This rad tool will run over your entire codebase, converting all .js(x) files to .ts(x).
I know, I know, this feels dirty. It defaults to using the dreaded any datatype, which is a preferential no-no. In places where it can't determine how types should interact, it inserts a comment telling Typescript to ignore the next line. Again, I know, I know, this isn't feeling any less dirty.
BUT listen. These JS files are already essentially behaving this way. There are no types, so everything is already an any.
So regardless of the ick, this has at least two immediate strategic advantages:
- Integrating new components into old components is now type-safe. Prior to this change, they may as well have been regular old JS when we had to put them in old code.
- This means now our new Typescript code is pulling up the quality of these old files rather than the old files pulling down the whole codebase.
- Every single place that needs attention to be really Typescript-ready is now marked by a comment or an any datatype. We try to clean up any old file that gets touched, one file at a time. Enumerating the scale of a problem can be time-consuming itself - with this approach, it's already done.
It's code that explains how it's supposed to be used. What's not to love about that?
I know that some of that "dirty" feeling will linger for some of you, but I'm telling you - your life will be better for it. Ours is definitely better. We were able to disallow JS files, thus further forcing adoption. We have a clear enumeration of our remaining JS debt. And cleaning up old files has become an easy add-on to existing work rather than an insurmountable mess.
The positive advantages far outweigh any concerns about mess created by an automated process. This wasn't clear before we used it, but it's crystal clear in hindsight. Isn't it always?
Embrace the future - it only takes a little while and you won't regret it.
EN 
ES 
FR 
DE 
DE_AT 
IT
This is a great read for any JS developer hesitant about migrating to TypeScript. The authors honest take on the dirty feeling of automated conversion and how it ultimately improves code quality is relatable and inspiring. Highly recommend!