TypeScript: In defense of any

A couple of days ago I found this beauty on the internet: Give up and use any. That’s a fantastic website, absolutely hilarious! It also shows how much TypeScript has grown in popularity. You have to have a certain reach to get critics to create websites like this.

Let’s put the fact that there’s a website aside for a moment and talk about its message: Use any. There has been quite a movement in the past that folks absolutely shouldn’t use any. Even the TypeScript handbook says so in its Do’s and Dont’s. In my book, there’s one lesson of 50 dedicated to the problem with any and that it’s wise to avoid it. But here’s a twist, and this might be controversial to some of you: I think using any in TypeScript is absolutely ok.

JavaScript’s default #

Ok, before you start screaming at your screen and open your Twitter client to shout at me, hear me out. TypeScript is a gradual type system. The possibility to turn on typings as much as you like is part of its design. I also think this is one of the reasons TypeScript is so immensely popular.

any is JavaScript’s default. JavaScript has types, but there is no type-checking. any is TypeScript’s way of saying: Turn off type-checking for me. And this can be helpful in some scenarios. For example:

Migrating from JavaScript. #

When you go from JavaScript to TypeScript, chances are that you already have a large codebase with a lot of implicit information on how your data structures and objects work. It might be a chore to get everything spelled out in one go. any can help you migrate to a safer codebase incrementally.

Using third party libraries with poor type support #

You might have one or the other JavaScript dependency that still refuses to use TypeScript (or something similar). Or even worse: There are no up-to-date types for it. Definitely Typed is a great resource, but it’s also maintained by volunteers. It’s a formalization of something that exists in JavaScript but is not directly derived from it. There might be errors (even in such popular type definitions like React’s), or they just might not be up to date!

This is where any can help you greatly. When you know how the library works, if the documentation is good enough to get you going, if you use it sparingly, any can be a relief instead of fighting types.

Smooth criminal development #

In the last couple of articles I wrote about why some things work different in TypeScript than in JavaScript. This has a lot to do with trade-offs the TypeScript team has to make to ensure type safety for edge cases. Yes, in your current scenario, JavaScript would work like that. But there are scenarios where your software might horrendously break.

In cases like this, any can help you to switch off type checking for a moment because you know what you’re doing. And since you can go from every type to any, but also back to every other type, you have little, explicit unsafe blocks throughout your code where you are in charge of what’s happening. This is what I call Smooth criminal development.

Know what it does #

Btw. here is what I had to say in TypeScript in 50 Lessons: any is a wildcard! Use any and you can go all out and forget about any type-checking at all. So why does something like any even exist?

This is due to the nature of JavaScript. In JavaScript, you are not bound to a type, and values from any type can appear in your variables and properties. Some developers make excessive use of that!

any reflects JavaScript’s overarching flexibility; you can see it as a backdoor to a world where you want neither tooling nor type safety. By all means, use any, but understand how it works and what to do with it – use it at your own risk!

Be certain that you want to use any explicitly as a type annotation. And if you want to enter through the backdoor to JavaScript flexibility, be very intentional through a type assertion:

// theObject is an object we don’t have a type for,
// but we know exactly what
// we are doing!
(theObject as any).firstLetter.toUppercase()

Of course, type assertions also work with other types. If you want to make sure you don’t have any somewhere in your code you don’t expect it to be, set the compiler flag noImplicitAny to true. TypeScript will then make sure that you either assign values to correctly infer types or, in the case of any, make sure that you explicitly annotate.

// deliveryAddress is of type any, because we
// didn’t annotate a specific type. Implicit anys are
// hard to track down later on, that’s why it’s good
// to have TypeScript scream at us
function printAddress(deliveryAddress) {
 console.log(deliveryAddress)
}

If we annotate function parameters and variables explicitly with any, they become easier to track down later on once we have decided on the real types.

Consider unknown #

any has a counterpart called unknown. It’s a top type as well, encompassing all possible values. The usage is different, though. Where any allows us to do everything, unknown doesn’t allow us to do anything. This can work in a lot of scenarios where you don’t know which type you’re dealing with (e.g. passing around arbitrary data that can’t be formalized in a generic variable).

function selectDeliveryAddress(addressOrIndex: unknown): string {
  if(typeof addressOrIndex === 'number' && 
    addressOrIndex < deliveryAddresses.length) {
    return deliveryAddresses[addressOrIndex]
  }
  return addressOrIndex; //💥 Error!
}

Boom! This is exactly what we want: “Type number is not assignable to type string.” We must do type checks and trigger control flow analysis; otherwise, TypeScript will throw an error.

Bottom line #

So here’s the bottom line: any is ok if used carefully. Turn on noImplicitAny, so you have to annotate every usage of it. Being explicit is key.