Become a member
to unlock all features

Level Up!

Access all courses & lessons on egghead today and lock-in your price for life.


    Increase TypeScript's type safety with noImplicitAny

    Basarat Ali SyedBasarat Ali Syed

    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.



    Become a Member to view code

    You must be a Member to view code

    Access all courses and lessons, track your progress, gain confidence and expertise.

    Become a Member
    and unlock code for this lesson




    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.