What are these strict compiler options in TypeScript: Part 2

Kyrylo Reznykov
Jan 25 · 4 min read
Type system in TypeScript

That is the second part of the previous article. Here I will cover all remaining strict options of the TypeScript compiler keeping article as simple as possible for understanding without going to far into details.


- - strictFunctionTypes

This option fixes what is, in my opinion, a bug in the TypeScript compiler. If it’s not a bug, then it was just a bad design decision and the appearance of a new compiler option proves my point. Let’s start with an example, by default, the next code will be compiled without any problem:

// Focus all your attention on callback signature
// It has
date parameter which is a union type
getCurrentYear(callback: (date: ) => ) {
(Math.random() > 0.5) ? '2020' : 2020;
}
// note that we ignored the fact that in 50% cases our callback returns type instead of .getCurrentYear((date: ) => {
console.log(date.charAt(0)); // in 50% it is
});

So that arrow function passed to getCurrentYear narrows down the type of “date” parameter and TypeScript doesn’t care about it. However, the same trick in a different context with variables even without any strict rule would produce an error:

x: | = (Math.random() > 0.5) ? '2020' : 2020;
y: = x; //

This makes much more sense and enabling --strictFunctionTypeswill ask a compiler to follow the same behavior in callback functions. That definitely will help you to prevent some bugs in a big project.

- -strictNullChecks

Every developer who consciously writes code encounters situations when he is not sure whether the value which he gets can be and whether he needs to write code that handles it. As a result, if you are reasonably paranoid you end up with a lot of unnecessary checks for or On the other hand, some sloppy programmers who don’t care about such small things may create a runtime error. Enabling --strictNullChecks flag will make it easier to reason about unfamiliar functions and will help each kind of developer to handle and appropriately in their codebase.

For the sake of example lets imagine that we have the next code which compiled without this flag:

// some unfamiliar function from 3rd party module
getUserId(isLogged: ): {
isLogged ? 100 : null;
}
// somewhere in your code
id: = getUserId();
id.toString(); since id is null..

Ops we didn’t notice that id can be null in that case and didn’t do any check for that. But if we would compile with --strictNullChecks flag we would get the next compilation error during the build:

: Type  is not assignable to type .
Type is not assignable to type .

So if we, in fact, want to return that from the function then we need to change our type annotations like this:

getUserId(isLogged: ):  {
isLogged ? 100 : null;
}
id: = getUserId();id.toString(); error since id can be null..

- -strictPropertyInitialization

That flag is an extension of the previous one (--strictNullChecks) and you have to enable both to make it work. It applies the same constraint to a class property type definition. If we compile the next example without this rule, everything is gonna be okay even if the previous flag (--strictNullChecks) is already enabled:

User {
name: ;
setName(name: ) {
this.name = name;
}
}
user = new User();
user.setName('John');

But if we enable --strictPropertyInitialization then our code wouldn’t compile producing the next error:

The idea is that if we indeed expect a name to be after we construct our object we need to define name field type as “If an name is a mistake then you have to make sure that it has some default non-null value assigned or initialized during object construction. So that will work:

User {
name: ;
setName(name: ) {
this.name = name;
}
}

- -alwaysStrict

That option is the simplest one. Your code will be parsed in an ECMAScript 5 strict mode and the "use strict" directive will be added to the top of each output module. Really, nothing to explain here.


Conclusion

I hope that now you clearly understand all the advantages of strict mode and whenever it is possible will compile your next TypeScript project using it.

JavaScript in Plain English

Learn the web's most important programming language.

Kyrylo Reznykov

Written by

I am a skillful developer who has experience in mobile development, enterprise java applications, and ultra-modern UI interfaces with offline-first design.

JavaScript in Plain English

Learn the web's most important programming language.

More From Medium

More from JavaScript in Plain English

More from JavaScript in Plain English

More from JavaScript in Plain English

5 Secret features of JSON.stringify()

More from JavaScript in Plain English

More from JavaScript in Plain English

7 really good reasons not to use TypeScript

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade