But most system also ingest external data -- that data truly is "unknown" until you parse/validate it. Once you do parse/validate it, you're going to want it to have the correct type.
You shouldn't "never" use. You should only use it in limited, constrained ways, and always with other controls that are sufficient to ensure it's correct.
I have usually explained to my teams that you only should be doing this at the boundaries of the system. User input, raw files, request bodies, etc. are places where you would _need_ to determine an actual type for an otherwise unknown value.
Even then, a solid validation/parsing library like Zod is a better choice than casting, it is much less error prone at ensuring you have the right type applied.
Beyond that boundary, casting with `as unknown` is a massive code smell and often introduces any further use of that data to invalid type errors. I'll refer to this as "force casting", because simply casting "x as T" with sufficient strictness configured will still fail type checking if x is not compatible with T, and that can be fine for certain cases like reducing a complex type or giving an inferred parser type a form that fits your domain types.
Developers that force cast too readily can end up creating hundreds or even thousands of type errors in the codebase over time, and they are pretty quickly revealed once you peel away the casting. The same is true when starting from an `any`, where every reference thereon is equivalent to a force cast.
There can be some complex typing scenarios that do require it, but even then a good type guard works better even if certain cases can be semantically equivalent, you can write tests around guards as they're just functions, ensuring some logical correctness to the typing.
The simplest but maybe odd way to judge whether a casting is used the wrong way is to ask "are you lying to the type system?". If so, how can you better portray that type correctly (validation that determines a correct type for you (e g. Zod) or type guards).
Yes, using something like zod at boundaries is the right approach.
(Personally, I'm not convinced zod itself is the way to go -- I'm suspicious of its lack of stability. The last thing I want to do is redevelop the boundaries of my system in a few years because zod 4 has been killed off in favor of zod 5, and then again in a few more years for zod 6, etc.)
> But most system also ingest external data -- that data truly is "unknown" until you parse/validate it.
Absolutely. And there are tools like Zod or e2e type safety solutions to solve this exact problem. And otherwise that data will come in as `any` or already as `unknown` so there will never be a use case for `as unknown as B`. This only happens when the data has already been assigned a type (here, the type is A). Now you're working on recasting it to fix your mistake instead of fixing the core issue of the incorrectly typed data.
The `A as unknown as B` workaround is only relevant when TypeScript believes A and B are so drastically different that they have nothing in common and shouldn't be cast as each other. The reason TypeScript believes that is either because it's true or because you made some earlier mistake.
TL;DR: This article is about fixing your own mistyping and not about typing something that lacks any. It's not about the boundaries of your application but about the internal workings
Mostly true.
But most system also ingest external data -- that data truly is "unknown" until you parse/validate it. Once you do parse/validate it, you're going to want it to have the correct type.
You shouldn't "never" use. You should only use it in limited, constrained ways, and always with other controls that are sufficient to ensure it's correct.