Increase TypeScript's type safety with noImplicitAny
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.
[00:01] 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.
[00:22] 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.
[00:44] 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.
[01:03] 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.
[01:22] 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.
[01:36] 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.
[01:55] 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.
[02:17] If you set it to true, you will notice that index access is no longer flagged for any.
Member comments are a way for members to communicate, interact, and ask questions about a lesson.
The instructor or someone from the community might respond to your question Here are a few basic guidelines to commenting on egghead.io
Be on-Topic
Comments are for discussing a lesson. If you're having a general issue with the website functionality, please contact us at support@egghead.io.
Avoid meta-discussion
Code Problems?
Should be accompanied by code! Codesandbox or Stackblitz provide a way to share code and discuss it in context
Details and Context
Vague question? Vague answer. Any details and context you can provide will lure more interesting answers!