any vs unknown en TypeScript: diferencias y cuándo usar cada uno

any y unknown aceptan cualquier valor. La diferencia está en lo que puedes hacer después con el valor: any te deja hacer cualquier cosa y no comprueba nada, mientras que unknown no te deja hacer casi nada hasta que demuestras qué es el valor.

let a: any = "hello";
let u: unknown = "hello";

console.log(a.toUpperCase()); // HELLO: any allows every operation

// @ts-expect-error: 'u' is of type 'unknown'.
u.toUpperCase();

if (typeof u === "string") {
  console.log(u.toUpperCase()); // HELLO: u is a string inside this block
}

Sin la línea @ts-expect-error, u.toUpperCase() es el error de compilación TS18046. La comprobación con typeof estrecha u a string, y dentro de ese bloque están disponibles todos los métodos de string.

any frente a unknown de un vistazo

En términos de teoría de tipos, unknown es el tipo superior: cualquier tipo se le puede asignar, y él solo se puede asignar a unknown y a any. any es una escapatoria que se puede asignar en los dos sentidos, a todo excepto a never.

any desactiva la comprobación de tipos

Un valor de tipo any se acepta a ciegas. El compilador acepta erratas, tipos incorrectos y propiedades que faltan, y los errores aparecen en tiempo de ejecución.

const user: any = { name: "Ada" };

const total: number = user.name; // compiles: any is assignable to number
console.log(typeof total);       // string

const city = user.adress;        // typo, still compiles
console.log(city);               // undefined

try {
  console.log(user.address.city); // compiles, throws at runtime
} catch (e) {
  console.log((e as Error).message);
}

La salida muestra el problema: una variable anotada como number contiene un string, y la última línea lanza Cannot read properties of undefined (reading 'city'). Además, any se propaga. user.name es any, así que cualquier valor calculado a partir de él es any, y un solo valor sin tipo puede desactivar la comprobación lejos de donde entró.

unknown te obliga a comprobar primero

Con unknown, el compilador rechaza cualquier operación hasta que el código estrecha el valor. El estrechamiento usa comprobaciones normales de JavaScript, y dentro de cada rama el valor tiene el tipo comprobado.

function describe(value: unknown): string {
  if (typeof value === "string") return `string of length ${value.length}`;
  if (typeof value === "number") return `number ${value.toFixed(2)}`;
  if (Array.isArray(value)) return `array of ${value.length}`;
  if (value instanceof Date) return `date ${value.toISOString()}`;
  if (value === null) return "null";
  if (typeof value === "object" && "id" in value) return `object with id ${String(value.id)}`;
  return typeof value;
}

console.log(describe("hi"));                               // string of length 2
console.log(describe(3.14159));                            // number 3.14
console.log(describe([1, 2, 3]));                          // array of 3
console.log(describe(new Date("2024-03-15T10:30:00Z")));   // date 2024-03-15T10:30:00.000Z
console.log(describe({ id: 7 }));                          // object with id 7
console.log(describe(undefined));                          // undefined

La comprobación value === null tiene que ir antes que la de objeto, porque typeof null es "object". Tras "id" in value, TypeScript sabe que el objeto tiene una propiedad id, de tipo unknown, porque nada dice qué contiene. String() la convierte en texto de forma explícita; para usarla como número tendrías que comprobarla antes con typeof.

También puedes saltarte la comprobación con una aserción, value as string, y el compilador la acepta. Es una promesa sin ninguna comprobación en tiempo de ejecución detrás, así que es preferible una comprobación real; consulta aserciones de tipo.

Validar JSON con unknown

JSON.parse está declarado para devolver any, así que su resultado desactiva la comprobación sin avisar. Anota el resultado como unknown y escribe un type guard que compruebe la forma antes de que el resto del código se fíe de ella.

interface Settings {
  theme: string;
  fontSize: number;
}

function isSettings(v: unknown): v is Settings {
  return (
    typeof v === "object" && v !== null &&
    "theme" in v && typeof v.theme === "string" &&
    "fontSize" in v && typeof v.fontSize === "number"
  );
}

const inputs = ['{"theme":"dark","fontSize":14}', '{"theme":"dark"}'];

for (const text of inputs) {
  const data: unknown = JSON.parse(text);
  if (isSettings(data)) {
    console.log(`${data.theme} at ${data.fontSize}px`);
  } else {
    console.log("invalid settings:", text);
  }
}

La primera entrada imprime dark at 14px, la segunda se rechaza porque falta fontSize. Con any, la segunda entrada habría seguido adelante como un Settings con fontSize indefinido. Para esquemas grandes, una librería de validación hace el mismo trabajo y deriva el tipo por ti.

noImplicitAny

any no solo aparece cuando alguien lo escribe. Un parámetro sin anotación y sin contexto del que inferir también sería any. La opción noImplicitAny, que activa strict, lo informa como error:

// This does not compile: x has no type
function double(x) {
  return x * 2;
}

console.log(double(4));

index.ts(2,17): error TS7006: Parameter 'x' implicitly has an 'any' type.

La solución es una anotación, function double(x: number). Escribir x: any de forma explícita también compila, y esa es la idea: any sigue siendo visible en el código y se puede buscar y revisar.

Por dónde se sigue colando any

Incluso con strict, estas cosas producen any sin que la palabra aparezca en tu código:

La variable de catch es unknown con strict porque se puede lanzar cualquier cosa, no solo objetos Error. Estréchala con e instanceof Error antes de leer e.message.

Cuándo es aceptable any

any no está prohibido, pero cada uno es un punto que el compilador deja de proteger. Usos razonables:

• Migrar un proyecto de JavaScript, donde any marca lo que todavía no está tipado.
• Código que el sistema de tipos no puede expresar bien, pequeño y detrás de una firma de función tipada.
• Código de tests que pasa datos incorrectos a propósito.

Para todo lo demás, unknown cubre el mismo caso de «no conozco este tipo» manteniendo las comprobaciones. Muchos equipos lo imponen con la regla de lint @typescript-eslint/no-explicit-any. Un tipo relacionado, Record<string, unknown>, es la opción habitual para «un objeto con valores desconocidos».