Check out a free preview of the full TypeScript 3 Fundamentals, v2 course:
The "Strict Mode" 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 describes the third step in converting JavaScript to TypeScript, and answers an audience question about when it makes sense to convert JavaScript to TypeScript.

Get Unlimited Access Now

Transcript from the "Strict Mode" Lesson

[00:00:00]
>> Mike North: The third thing you're going to do as the third pass is in small chunks because there's really no benefit to doing this in a huge single pass. You're going to turn on strict TypeScript compiler settings. So the strict null checks, that makes it so that null it's not regarded, sorry I don't wanna use a double negative here.

[00:00:26] With strict null checks set to false, null is regarded as a valid value in any type. Not the any type, but you could have a number whose value is null. So null fits anywhere. Strict null check, set to true, makes it so that the only thing that can hold the null is null.

[00:00:52] And that's where you're gonna start shaking out, branches of your code that returned null and now you'll have to start introducing the intersection operator with this function returns the string or null. Strict true turns on a bunch of strictness settings, I won't go too deeply into that. Strict function types it validates arguments and return types of callback types.

[00:01:23] So if you say, I take a mouseListener function as an argument, strictFunctionTypes will more rigorously type match against everything you try to pass to it. And Bind, Call, Apply, we've already looked at, that makes sure that the arguments passed to function bind, call, and apply and the lexical scope all type check appropriately.

[00:01:46] And normally, without that last flag set to true, bind, call, and apply, you basically lose all type safety through going into those functions. So this is where you're trying to get rid of as many explicit anys as you can and replace them with more meaningful types. And you wanna avoid casting, which is where you're forcing TypeScript to regard something as a particular type.

[00:02:16] That is done with the as keyword, so you'd say, regard this as a string. The more of that you introduce into your app, the more your types have a chance of lying to.
>> Speaker 1: So I mean, what is the benefit of uplifting an existing code base to TypeScript?

[00:02:39]
>> Mike North: They are the same benefits of using TypeScript in the first place.
>> Speaker 1: The amount of work you are talking about, and does that justify those benefits?
>> Mike North: So it kinda depends on a case-by-case basis. For example, if you're talking about some of these really small JavaScript modules that do one thing and one thing only, left pad would be a good example of this, right?

[00:03:04] It's adding a prescribed amount of white space to the beginning of the string, I'm not sure there's a whole lot of value in converting that kind of thing to TypeScript. However, if you want to use TypeScript elsewhere on code that is lacking types, someone has to provide that type information.

[00:03:23] You have two choices, you either can, through something I'll show you later, say, regard this whole module as an any, like anything goes. When I import something from this module, let me do whatever I want. You could do that but that's risky for the same reason any is a risky elsewhere.

[00:03:44] The other option is every consumer of your library has to kind of fill in the type information, at least for the portion they wish to use. Because the compiler it is performing a holistic analysis of your app, which includes all of it's dependencies. So, missing type information for dependencies that causes weakness in any app that depends on that code.