Suppose some value comes from: an API response JSON.parse local storage a message payload third-party code
An HTTP response does not become a User just because our application expects a User.
unknown is not missing type information. It is an honest description of a value we have not verified yet.
It does not inspect the runtime value. It does not add missing properties. It does not turn 123 into a string.
That means we can test it independently, reuse it somewhere else, or compose it into something larger.
It does not: clone the value coerce the value generate a new object transform invalid data into valid data
That is often useful for API responses because a server may add a new field without breaking an older client.
A type guard toolkit and a schema library overlap a little, but they are not trying to solve exactly the same problem.
For example, a schema library is probably the better choice when we need: structured validation errors with field paths multiple validation issues at once coercion default values transformations schema-generated types or external artifacts deep integration with a form or API framework
| Approach | Good fit | | ---------------------- | ----------------------------------------------------- | | Inline typeof checks | One small local condition | | Type guards | Reusable boolean validation and narrowing | | Schema library | Rich validation, transformation, and schema workflows |
If you want to see the full guide, including JSON boundaries, exact objects, and custom domain refinements: