Enter Your Email Address to Watch This Lesson

Your link to unlock this lesson will be sent to this email address.

Unlock this lesson and all 986 of the free egghead.io lessons, plus get TypeScript content delivered directly to your inbox!



Existing egghead members will not see this. Sign in.

Increase TypeScript's type safety with noImplicitAny

2:24 TypeScript lesson by

TypeScript tries to infer as much about your code as it can.

But sometimes there really is not enough context for it to infer reliably. If it tried to do such inference it would potentially result in more nuisance than help. So instead it infers the type any. This type can catch people off guard as it provides very little type safety. Fortunately TypeScript has a flag to make it easier to catch such unsafe code at development time.

Get the Code Now
click to level up

egghead.io comment guidelines

Avatar
egghead.io

TypeScript tries to infer as much about your code as it can.

But sometimes there really is not enough context for it to infer reliably. If it tried to do such inference it would potentially result in more nuisance than help. So instead it infers the type any. This type can catch people off guard as it provides very little type safety. Fortunately TypeScript has a flag to make it easier to catch such unsafe code at development time.

Let's go ahead and declare a variable without assigning to it. At this point, TypeScript cannot infer the type of the variable, so it infers any. Similarly, if you have a function that takes two parameters and returns their sum, there is no way for TypeScript to be sure if, for example, A and B were meant to be numbers or strings.

In this case, TypeScript will go ahead and infer the type of A, B and the return of the sum function to be any. The reason why any is bad is because it is compatible with all types. For example, we can go ahead and call the sum function with two Booleans, which is almost definitely a misusage of the sum function.

Similarly, we can even assign a Boolean to the last summed result, which again is almost definitely a user error. To catch all the cases where TypeScript cannot infer reliably the internal type of a variable or a parameter, you can enable the flag noImplicitAny in your tsconfig.

As soon as you set this to true, you can see that all the places that previously TypeScript was inferring the type any now become errors. You can fix these errors quite simply by adding explicit annotations to all the places that are being inferred as type any.

As soon as we do that, the errors now cascade, to the misusages of the variable and the function call, which in turn can be removed by calling the function with the right arguments and assigning the right types to the variable.

One thing to be aware of with noImplicitAny is that it also prevents index access into objects. As an example, consider an object foo that has a few members. We can go ahead and get all of its values using object.keys and mapping each key to a value in foo.

You will see that TypeScript will complain that foo does not have an index signature, and therefore this index access into foo with the key has an implicit type any. If you still want to write dynamic code like this, TypeScript makes it easy without having to focal all of implicit any by adding a suppressImplicitAnyIndexErrors flag.

If you set it to true, you will notice that index access is no longer flagged for any.

HEY, QUICK QUESTION!
Joel's Head
Why are we asking?