This course has been updated! We now recommend you take the React and TypeScript, v2 course.

Check out a free preview of the full React and TypeScript course:
The "Migrating from JavaScript" Lesson is part of the full, React and TypeScript course featured in this preview video. Here's what you'd learn in this lesson:

Steve discusses a recommended path for migrating from JavaScript to TypeScript to ease the transition. Setting a gentle set of TypeScript rules and the allowJs flag to avoid throwing errors at any types.

Get Unlimited Access Now

Transcript from the "Migrating from JavaScript" Lesson

>> One common question that comes up a little bit is about the migration piece. We can talk about a little bit, like I'm gonna warn you that there is no perfect answer for this. But we can kind of talk about it a little bit. There is some kind of official advice in the reaction guides.

[00:00:16] I've talked to a lot of different teams about how some of the different ways to go about this. Basically this entire course, we have used the strictest mode of Type Script. Right, we've say like, don't allow anything to implicitly be the type of any. Right? We don't allow any kind of accidental ways that JavaScript can cause anything to work.

[00:00:44] And we haven't allowed any JavaScript files. That doesn't work for a large code base. The problem though is that large code bases are all specially unique in their own ways. But some of the kinda high level advice that I will give around this is one. There isn't allowed JS flag.

[00:01:05] This will allow your Type Script compiler, to import files that are JavaScript. And what it will do in that case, it will go in, and it will try to basically define everything as any. So you have to have, the ability to allow implicit any. And you will not get any tapes, if you'll basically be a JavaScript app.

[00:01:24] And at that point, you can start converting stuff over like kind of piecemeal. One of the rules that we did and like we were doing a major kind of rewrite of our application when we switch to Type Script. So we were kind of only a few months in, during the biggest one that we did.

[00:01:39] But part of it was basically like we allowed. We kept we kept the Type Script rules very very loose. But the rule was like if you touch it you have to type it, right? And so, if you were gonna commit a file and change a file you have to get it up to speed.

[00:01:56] And sometimes that snowballs and gets a little bit out of control at which point you talk about it as a team and figure out where to draw the line. Cuz if it's like, yeah, I was gonna do this like quick change this one file. And I was supposed to be like a two point ticket and it spiraled out of control.

[00:02:13] There's a decision to make the team but you kinda start with the kind of most wide and broad and loose Type Script rules. You begin to tighten them up over time. There are tools that will go through at least try to like statically analyze your code as well.

[00:02:29] And start to put in some of those types for you, that'll work as well. But I think the general like high level advice is yeah. It is super compelling, we struggled with this as a team. It is super compelling to want to go like yeah, we're gonna do this type of thing.

[00:02:46] We're gonna do it right. In a way you start a new code base, you're like, this is could be the code base. Where we don't accrue any tech debt cuz we're gonna do everything right. And then yeah, check into that code base two years later, right. Priorities and stuff happens but I think being really okay with having some of the more loose in general ones.

[00:03:05] And then figuring out for your code base, what the plan of action is. This is not solely a technical problem. This also becomes like just a collaboration as what the what the agreement is and how we're going to do this. And how do we work together on it and it's like, maybe you have to talk about this.

[00:03:23] But I think using the loose versions of the tools. There's also and this is kind of more Type Script seven than Type Script and react. But for many libraries, some of them include types in the NPM packages. For other ones you can NPM install, at types slash the name of the package.

[00:03:44] Which is community driven types that you can use for. So you would say, all right, we're gonna use the loose version of our dependencies. And then we're also gonna install the type definitions for our dependencies that support them. And so you start to get most of the way there, and you can start to allow JS and then okay.

[00:04:01] Eventually we're going once we know we've converted all the files over and we did an effort around. It wasn't just like as we touched on we did as we committed new files or changed files. But we also had a certain number of points every sprint to go and convert as many files as possible.

[00:04:16] And just kind of work that out with product as well. So there isn't necessarily a right answer on I think depends on the code base. It depends on your team depends on a lot of the constraints that you have at the time. But I think the large scale rewrite never works.