How To Strongly Type process.env
Learn how to strongly type process.env in TypeScript by either augmenting global type or validating it at runtime with t3-env.
any
is an extremely powerful type in TypeScript. It lets you treat a value as if you were in JavaScript, not TypeScript. This means that it disables all of TypeScript's features - type checking, autocomplete, and safety.
ts
constmyFunction = (input : any) => {input .someMethod ();};myFunction ("abc"); // This will fail at runtime!
Using any
is rightly considered harmful by most of the community. There are ESLint rules to prevent its use. This can turn developers off using any
entirely.
However, there are a few advanced cases where any
is always the right choice. Here are some of them:
Let's imagine we wanted to implement the ReturnType
utility in TypeScript. This utility takes a function type and returns the type of its return value.
We need to create a generic type which takes a function type as a type argument. If we restricted ourselves to not use any
, we might use unknown
:
ts
typeReturnType <T extends (...args : unknown[]) => unknown> =// Not important for our explanation:T extends (...args : unknown[]) => inferR ?R : never;
It's not important to understand all of this code, only the constraint - T extends (...args: unknown[]) => unknown
. What we're saying here is that only functions which accept an arguments array of unknown[]
and return unknown
are allowed.
It seems to work fine for functions which have no arguments:
ts
constmyFunction = () => {console .log ("Hey!");};typeResult =ReturnType <typeofmyFunction >;
But it stops working as soon as we add an argument:
ts
constmyFunction = (input : string) => {console .log ("Hey!");};typeType '(input: string) => void' does not satisfy the constraint '(...args: unknown[]) => unknown'. Types of parameters 'input' and 'args' are incompatible. Type 'unknown' is not assignable to type 'string'.2344Type '(input: string) => void' does not satisfy the constraint '(...args: unknown[]) => unknown'. Types of parameters 'input' and 'args' are incompatible. Type 'unknown' is not assignable to type 'string'.Result =ReturnType <typeofmyFunction >;
In fact, it only works if we change the parameter of our function to input: unknown
:
ts
constmyFunction = (input : unknown) => {console .log ("Hey!");};typeResult =ReturnType <typeofmyFunction >;
So accidentally, we've created a ReturnType
function that only works on functions which accept unknown
as an argument. This is not what we wanted. We wanted it to work on any function.
The solution is to use any[]
as the type argument constraint:
ts
typeReturnType <T extends (...args : any[]) => any> =T extends (...args : any[]) => inferR ?R : never;constmyFunction = (input : string) => {console .log ("Hey!");};typeResult =ReturnType <typeofmyFunction >;
Now it works as expected. We're declaring that we don't care what types the function accepts - it could be anything.
The reason this is safe is because we're deliberately declaring a wide type. We're saying "I don't care what the function accepts, as long as it's a function". This is a safe use of any
.
In some places, TypeScript's narrowing abilites are not as good as we'd like them to be. Let's say we want to create a function which returns different types based on a condition:
ts
constyouSayGoodbyeISayHello = (input : "hello" | "goodbye") => {if (input === "goodbye") {return "hello";} else {return "goodbye";}};constresult =youSayGoodbyeISayHello ("hello");
This function isn't really doing what we want it to. We want it to return the type "goodbye"
when we pass in "hello"
. But currently, result
is typed as "hello" | "goodbye"
.
We can fix this by using a conditional type:
ts
constyouSayGoodbyeISayHello = <TInput extends "hello" | "goodbye">(input :TInput ):TInput extends "hello" ? "goodbye" : "hello" => {if (input === "goodbye") {return "hello";} else {return "goodbye";}};constgoodbye =youSayGoodbyeISayHello ("hello");consthello =youSayGoodbyeISayHello ("goodbye");
We've added a conditional type to the return type of the function which mirrors our runtime logic. If TInput
, inferred from the runtime argument input
, is "hello"
, we return "goodbye"
. Otherwise, we return "hello"
.
But there's a problem. I've deliberately disabled the errors in the snippet above. Let's see what happens when we enable them:
ts
constyouSayGoodbyeISayHello = <TInput extends "hello" | "goodbye">(input :TInput ):TInput extends "hello" ? "goodbye" : "hello" => {if (input === "goodbye") {Type '"hello"' is not assignable to type 'TInput extends "hello" ? "goodbye" : "hello"'.2322Type '"hello"' is not assignable to type 'TInput extends "hello" ? "goodbye" : "hello"'.return "hello";} else {Type '"goodbye"' is not assignable to type 'TInput extends "hello" ? "goodbye" : "hello"'.2322Type '"goodbye"' is not assignable to type 'TInput extends "hello" ? "goodbye" : "hello"'.return "goodbye";}};
Ouch. TypeScript doesn't seem to be matching up the conditional type with the runtime logic. "hello"
or "goodbye"
can't be returned from the function.
We can fix this by using as
, and forcing it to be the correct conditional type:
ts
constyouSayGoodbyeISayHello = <TInput extends "hello" | "goodbye">(input :TInput ):TInput extends "hello" ? "goodbye" : "hello" => {if (input === "goodbye") {return "hello" asTInput extends "hello"? "goodbye": "hello";} else {return "goodbye" asTInput extends "hello"? "goodbye": "hello";}};
We can make this nicer by extracting that logic to a common generic type:
ts
typeYouSayGoodbyeISayHello <TInput extends "hello" | "goodbye"> =TInput extends "hello" ? "goodbye" : "hello";constyouSayGoodbyeISayHello = <TInput extends "hello" | "goodbye">(input :TInput ):YouSayGoodbyeISayHello <TInput > => {if (input === "goodbye") {return "hello" asYouSayGoodbyeISayHello <TInput >;} else {return "goodbye" asYouSayGoodbyeISayHello <TInput >;}};
But in these situations, it often makes more sense to use as any
:
ts
constyouSayGoodbyeISayHello = <TInput extends "hello" | "goodbye">(input :TInput ):TInput extends "hello" ? "goodbye" : "hello" => {if (input === "goodbye") {return "hello" as any;} else {return "goodbye" as any;}};
Yes, this does make our function less type-safe. We could accidentally return "bonsoir"
from the function instead.
But in these situations, it's often better to use as any
and add a unit test for this function's behavior. Because of TypeScript's limitations in checking this stuff, this is often as close as you'll get to type safety.
There are several other use cases like this, where inside generic functions you need to use any
to get around TypeScript's limitations. To me, this is fine.
A question remains: should you ban any
from your codebase? I think, on balance, the answer should be yes. You should turn on the ESLint rule which prevents its use, and you should avoid it wherever possible.
However, there are cases where any
is needed. They're worth using eslint-disable
to get around them. So, bookmark this article, and attach it to your PR's when you feel the need to use it.
Have you spotted any other legitimate use cases for any
? Let me know!
Share this article with your friends
Learn how to strongly type process.env in TypeScript by either augmenting global type or validating it at runtime with t3-env.
Learn why TypeScript's types don't exist at runtime. Discover how TypeScript compiles down to JavaScript and how it differs from other strongly-typed languages.
Improve React TypeScript performance by replacing type & with interface extends. Boost IDE and tsc speed significantly.
In this book teaser, we discuss deriving vs decoupling your types: when building relationships between your types or segregating them makes sense.
Learn how TypeScript's new utility type, NoInfer, can improve inference behavior by controlling where types are inferred in generic functions.
Learn how to set up TypeScript to bundle a Node app using pnpm, Node.js, TypeScript, and ES Modules for a seamless development experience.