Difference Between 'any,' 'unknown' and 'never' in TypeScript
Notes from Effective TypeScript by Dan Vanderkam

Search for a command to run...
Notes from Effective TypeScript by Dan Vanderkam

No comments yet. Be the first to comment.
This series shares lessons learned from Effective TypeScript as I read through the book.
Notes from Effective TypeScript
Short answer is: You can’t But there are other options! These options help you: Expand the … N more … values in your intellisense pop-up window Expand Type contracts to view all properties in a combined type without using the subtype names. 1 - U...
Introduction eBPF (extended Berkeley Packet Filter) is a successor to the BPF (Berkeley Packet Filter) which already existed as part of the Linux kernel as far back as 1992. It allows developers to safely extend the kernel based on sys-call events, a...
I'm about to host my own ATProto server. It's 01:09am my time, but I want to do this now, before bed, so that it doesn't distract me from important work tomorrow. If you don't know what this is visit: I have my first issue. The issue is that my doma...
I'm about to do my first ever domain transfer. It's from Squarespace to Cloudflare, and I hope it goes smoothly. I need to do this because Squarespace is woefully under-featured for the needs of building an indie sass product. I have a major concer...
And why you should be very intentionally optimizing your workflows with AI tools - they really help!
Try as we might, we won't always know what a type should be at every given point in time. In these situations it's important that we choose a suitable way to represent such a type which is both safe and broad enough. This is where any, unknown and never come in.
Recall that with Typescript we have these assignability rules for the any type.
any type.any type is assignable to any other type. Keep these in mind as we move on to talk about any, unknown, and never in terms of assignability rules.
anyThe any type obeys the two rules from our primer, but it's worth noting that the second rule isn't completely true, because the any type is not assignable to a type of never.

unknownThe unknown type obeys only the first rule:
unknown typebut not the second rule, because we can only assign the unknown type to another unknown type or the type any.

neverThe never type obeys only the second rule:
never type is assignable to any other typebut not the first rule, because we can never assign any other type to the type never, not even the type any.

Which type to choose depends on what you're doing.
Then keep the any type handy to tell the type checker to ignore some types while you perform your migration -- this seems to be the main reason any was created in the first place[3].
In essence, use the any type when you are sure you want to ignore type checking on a variable.
Other than this, I personally don't see a strong use case for any in a TypeScript codebase, given how dangerous it can be in allowing errors seep through from one function to another.
In cases where a type is unknown, it's advisable to use the unknown type and avoid the use of any. The main reason for this is because 'any' effectively silences the type checker when used, causing errors such as undefined to sneak in.
Instead, prefer unknown. The beauty of using 'unknown' to represent an unknown type is that when we try to access the properties of an 'unknown' type, the type checker reminds us that we're trying to perform a dangerous operation.
Now, the very fact that we're trying to access a property of an unknown type means we now know something about that previously unknown type. So a warning from TypeScript at that point is a great reminder to update our unknown type with the details we now know about it, before trying to access it.
As for never, it doesn't really help when dealing with migrations or values of unknown types, but it is the perfect type to use when we know a function will never run or never return anything.
This is different from void, in that we can expect a void function to return even after performing operations with no side effects or return values.
However, a never function will never return... it might throw an error, run infinitely, or simply represent code that will never be reached.
any handy.unknown type.never type.