Check out a free preview of the full TypeScript 3 Fundamentals, v2 course:
The "Converting to TypeScript" Lesson is part of the full, TypeScript 3 Fundamentals, v2 course featured in this preview video. Here's what you'd learn in this lesson:

Mike introduces the 3 step process of converting JavaScript to TypeScript, and first talks about what not to do.

Get Unlimited Access Now

Transcript from the "Converting to TypeScript" Lesson

>> Mike North: This is probably one of the most valuable things that I'm going to teach you in this workshop, and it is a recipe for converting from JavaScript to TypeScript. So one of the great things about TypeScript is it can inter-operate with JavaScript very, very easily. You're gonna have JS and TS modules side by side.

[00:00:23] You can import in one direction or the other and everything will be okay. Not a lot of programming languages give you this. So we shouldn't treat a transition from JavaScript to TypeScript as the same kind of change to a code base that would result from a change in one programming language to something totally unrelated.

[00:00:49] It's like rewriting something from Ruby to Rust. That is like apples and oranges, right? So I'm gonna lead you down a three-step process that will make it so this change can be made incrementally on a couple of files at a time. Or in multiple passes where you get to the endpoint you are looking to get without potentially running into creating extra work for yourself or disruption for people who depend on that code.

[00:01:22] First, let's talk about what not to do. What you don't want to do is mix a conversion from JavaScript to TypeScript with functional changes, and these can be subtle. It can be the difference between checking whether a value is truthy or not to a type of check, right?

[00:01:45] Is this truth versus check whether this value is undefined, no zero and empty string are gonna be handled differently. So you want to avoid even those kinds of functional changes if you can. You don't want to try this kind of conversion if your test coverage is really low.

[00:02:02] Because after each of our three steps run a test sweep like your test sweep for this piece of code, and ensure that not only have we converted to TypeScript, but the library still works the way we want it to work.
>> Mike North: You don't want to let the perfect be the enemy of the good.

[00:02:24] And in this sense what I mean is don't try to type things too strongly, too early on. Your goal is to get converted, and you'll start to see some benefits of the strong typing, but don't chase those benefits by trying to type things up prematurely. You want to get converted over and then start applying stronger typing where things make sense.

[00:02:52] The reason for this is, particularly if you convert a few files at a time, and you have some very strongly typed things. As soon as you convert some of the other files that interact with your already strong code, you don't have a chance to start out with sort of weak types.

[00:03:08] Cuz your constraints are already very tight, right? In one part of your app. So you kind of want to remember the goal is, get converted and then we'll ratchet things up. Don't forget to add tests for your types. Again, dts lint is the way you write tests that's specifically are for type information only.

[00:03:31] And also particularly for libraries, don't try to publish types for consumer use until you're happy with them. Because people take type information that comes along with the library as an indication of a public API. What you should do and what you shouldn't. Remember, it's developer intent. If you wrote this code in TypeScript in the first place, those types would express what you can do and can't do with piece of code.

[00:04:00] So if you prematurely have people using this stuff, and there's a bunch of looseness all over the place, you can lead them on a wild goose chase where they're assuming things should be doable and valid. And in fact that's not the case.