Why You Shouldn’t Use any TypeScript type | Saksham Khandelwal

Why You Shouldn’t Use any TypeScript type

What’s the point of using strictly typed extended JavaScript code if you’re going to try and get away with not strictly typing your code?

For example, if you’ve created a function that expects the return value to have a specific type, but a different type gets returned instead, TypeScript would flag the error.

You can easily solve the error so in a sense, it makes development faster too.

But, when you don’t specify a type, the any keyword is inferred. This means the type can be anything. According to the documentation, the compiler effectively treats any as “please turn off type checking for this thing”.

Why you shouldn’t use it

I want to say that you simply just shouldn’t use the any keyword because it defeats the purpose of using TypeScript.

It's not reliable

Typescript has the advantage of being reliable. When coding there are so many errors that can be prevented simply by specifying what type you expect to return.

Using any eliminates your ability to specify a type and even though your code won’t break, you might not get the desired result.

It slows you down when scaling your project

This is a major cause for concern.

Yes, your code may compile without any errors now while the project is small. And your project may even run without throwing errors as the project grows.

But there is a huge risk that you won’t get the desired result. For example, you might want a boolean returned from a function but a getting a string instead. That might be because a function is accepting any value.

Having an any type to get away from type checking can slow your ability to scale your project since it might take time to debug the error.

Especially if no error is thrown but the wrong result is returned.

Just use JavaScript instead

JavaScript is loosely typed while TypeScript is strongly typed.

If you’re going to overuse the any keyword, then you might as well just use JavaScript instead and save yourself some time by not doing any of the setup required.

When could you use it?

I prefer not to use the any keyword. But I’m sure there are some cases where you might need to use it.

When you just don’t know

Sometimes you just won’t know what the specific type will be.

You can find out but being able to find out might be a little limited, especially when using third-party packages.

Some third-party packages may return data whose type we don’t know. In such cases, it might be okay.

When you need some flexibility

I guess the any keyword exists for a reason.

Using it ensures that the compiler won’t generate any error at compile time. Again this flexibility might be because we don’t know what the data returned will look like.

When migrating from JS to TS

The TypeScript documentation says to not use the any keyword unless you’re moving from a JavaScript project to a TypeScript project.

In this case, you’d want to disable some type checking to avoid errors, especially when migrating a project in small parts.

How to avoid using the `any` keyword

The best way to avoid using any is by disabling its usage in the config file.

You can do this by opening the tsconfig.json file and under compilerOptions, add "noImplicitAny": true.

This means that TypeScript won’t infer anything as any. And when a type is given the any keyword, TypeScript will issue an error.