TypeScript
Diferencias entre any, unknown, never y void, cómo afectan la seguridad del tipado y cuándo utilizar cada uno sin ocultar errores.
Estos tipos describen relaciones especiales dentro del sistema, no categorías ordinarias como string o Product.
any → desactiva comprobación
unknown → cualquier valor, pero todavía no utilizable
never → ningún valor posible
void → el retorno no ofrece un valor útil al consumidorlet value: any = "hello";
value.nonExisting.method();
value = 10;
const product: Product = value;any permite casi cualquier operación y se propaga hacia otros tipos.
No significa únicamente “puede contener cualquier valor”; unknown también puede. La diferencia es que any evita que el checker te proteja.
JSON.parse.const value = JSON.parse(text);El resultado histórico es any, por lo que conviene asignarlo inmediatamente a unknown o pasar por un parser.
const value: unknown = JSON.parse(text);const user: any = loadUser();
const name = user.profile.name;name también termina como any. Los errores pueden recorrer varias capas sin diagnóstico.
Encapsula una frontera legacy y devuelve un contrato seguro.
let value: unknown = await loadValue();Puede recibir cualquier cosa:
value = "text";
value = 10;
value = null;Pero no puedes usarla sin reducir posibilidades:
value.toUpperCase();if (typeof value === "string") {
console.log(value.toUpperCase());
}Dentro de la rama, TypeScript conoce string.
try {
await saveProduct();
} catch (error: unknown) {
if (error instanceof Error) {
console.error(error.message);
}
}JavaScript permite lanzar cualquier valor:
throw "failed";
throw null;
throw { code: "FAILED" };Por eso asumir Error sin comprobar no es seguro.
acepta cualquier valor permite cualquier uso
any sí sí
unknown sí noUtiliza unknown en fronteras donde todavía debes demostrar qué recibiste.
function fail(message: string): never {
throw new Error(message);
}La función no produce un valor normal.
También puede no terminar:
function runForever(): never {
while (true) {}
}Si un union pierde todas sus posibilidades después del narrowing, el tipo resultante es never.
type Status = "idle" | "loading";
function describe(status: Status) {
if (status === "idle") return "Idle";
if (status === "loading") return "Loading";
status;
// never
}type Result =
| { status: "success"; value: string }
| { status: "error"; error: Error };
function render(result: Result): string {
switch (result.status) {
case "success":
return result.value;
case "error":
return result.error.message;
default:
return assertNever(result);
}
}
function assertNever(value: never): never {
throw new Error(`Unexpected value: ${String(value)}`);
}Si se añade otra variante, el default deja de recibir never y aparece un error.
type Value = string | never;Es equivalente a:
type Value = string;Añadir “ningún valor posible” no añade una posibilidad nueva.
function logMessage(message: string): void {
console.log(message);
}La función puede terminar normalmente, pero el contrato no entrega un valor útil.
function returnsUndefined(): undefined {
return undefined;
}Este contrato exige el valor undefined.
function returnsVoid(): void {
return;
}void comunica que el retorno debe ignorarse.
const numbers = [1, 2, 3];
const result = [] as number[];
numbers.forEach((value) => result.push(value));push retorna un número, pero forEach espera una callback cuyo resultado se ignora.
Una función que devuelve un valor puede ser compatible con () => void en muchos contextos porque el consumidor promete no utilizar ese retorno.
const handler: () => void = () => {
return 10;
};La llamada se ve como void:
const result = handler();El valor puede existir en JavaScript, pero el tipo impide depender de él mediante ese contrato.
Esto no significa que una función declarada explícitamente con retorno void pueda retornar cualquier expresión en todas las formas. La regla de compatibilidad de callbacks y la anotación de implementación tienen contextos distintos.
void → termina, pero no proporciona un valor útil
never → no alcanza una finalización normalfunction log(): void {
console.log("done");
}
function fail(): never {
throw new Error("failed");
}function requireValue(value: string | null): string {
if (value === null) {
throw new Error("Value is required");
}
return value;
}El retorno general es string, no never, porque algunas rutas terminan con un valor.
function migrate(value: any): Product {
return value;
}El retorno Product parece seguro, pero no se comprobó nada.
Mejor:
function migrate(value: unknown): Product {
return parseProduct(value);
}function getErrorMessage(error: unknown): string {
if (error instanceof Error) {
return error.message;
}
if (typeof error === "string") {
return error;
}
return "Unknown error";
}La función convierte una frontera abierta en un string estable para la UI.
string | never esperando representar un error.¿Por qué unknown es más seguro que any para una respuesta externa?
Porque ambos pueden contener cualquier valor, pero unknown obliga a comprobar su forma antes de acceder a propiedades u operaciones; any desactiva ese control.
null, undefined y ausencia explica cómo TypeScript diferencia un valor vacío, una propiedad ausente y una posibilidad todavía no comprobada.