The "any" type in Typescript - simple and short explanation

Probably one of the most debated types in Typescript is the any type. Some abuse it, some tell you to use it as little as possible. How does this work?

Imagine that we need to specify the type of a variable but we don't know exactly what that variable will hold when writing our code. These values may be dynamic (they might come from a 3rd party library, for example). In this case, the best approach would be not to check the type of the variable (half true, since we'are actually using a type to specify that we expect whatever and we're fine with it). We can do so by using the any type and let the variables to be dealt with at compile time. The any type doesn't look any different from the others and we write it like this:

This is also very useful when we work with arrays and we don't know the types of all its elements. To avoid issues we can do something like this:

Notice that in the first example, I specified I want an array of type number so when trying to push a string to it, I got an error. The second example passes successfully.

Image source: Christina Morillo/ @divinetechygirl on Pexels

Comments

[Basti Ortiz]

More often than not, the any type is used to denote some form of an object dictionary. For third-party libraries, this may be the configuration object and whatnot.

In those cases, I strongly advocate for the use of the Record<K, V> utility type. It's basically a wrapper over objects with index signatures, but it provides a greater level of type safety than a mere any type.

I can, for example, define a dictionary of string key-value pairs as Record<string, string>, which is definitely safer than any. For an extra level of protection, one can also use Record<string, string|undefined> instead in order to enforce null checks.

The any type should always be a last resort. Ideally, it shouldn't even be an option. In practice? Maybe not so.

[Ben Calder]

If all else fails: any

[Shawn Bullock]

I think any is a lot like the default JavaScript type. Can be anything, and become anything. I love TypeScript as much as anyone. But I'll say, to eliminate some of its complaining and still get more of what I want than what it wants, I have to decorate with any. Viva la any.

[Arika O]

I understand what you mean. There are, of course, situations when you know better what you want to do with the code. I personally prefer not to use it at all when I do not know a type, since it defeats the purpose of Typescript. At work I am using it together with Eslint so I can't really put it in my code at all :).

[Julian Garamendy]

Exactly. I think almost anything is better than any.

In the example above we could go from number[] to (number | string)[], instead of resorting to any[]. Or generics, depending on the case.

[Tomasz Kudlinski]

I think it is worth mentioning that where possible, use of any should be avoided. Typescript 3.0 introduced more safe replacement of any called unknown:

unknown is the type-safe counterpart of any. Anything is assignable to unknown, but unknown isn’t assignable to anything but itself and any without a type assertion or a control flow based narrowing. Likewise, no operations are permitted on an unknown without first asserting or narrowing to a more specific type.

docs about it

[Arika O]

True. This is the subject of my next actually :). Thx for mentioning it.

[John Peters]

Sometimes I have to use 3rd party libraries with no definition files. For that I use any, it works well but there's no intellisense.