TypeScript: JavaScript con tipos

Una anotación es el tipo que escribes tras dos puntos: let edad: number. Pero no hace falta ponerla en todas partes, porque TypeScript infiere el tipo a partir del valor. En const nombre = "Ana" ya sabe que es un texto, y en [1, 2, 3].map((n) => n * 2) sabe que n es un número.

La regla práctica: anota los parámetros de las funciones, que TypeScript no puede adivinar; los tipos de retorno de las funciones que otros van a usar; y los datos que llegan de fuera. Deja que infiera el resto. Para un valor del que no sabes nada, como el resultado de JSON.parse, usa unknown, que te obliga a comprobarlo antes de usarlo. any, en cambio, desactiva todas las comprobaciones.

interface Usuario { … } y type Usuario = { … } describen la misma forma de objeto y se usan igual. Una interfaz se amplía con extends; un alias de tipo, con una intersección (&). Los dos sirven para tipar props, respuestas de una API o el contrato que implementa una clase.

Las diferencias están en los bordes. Solo type puede nombrar cosas que no son objetos: uniones ("pendiente" | "pagado"), tuplas o tipos derivados de otros. Solo interface admite la fusión de declaraciones: si declaras dos veces la misma interfaz, TypeScript junta sus propiedades, algo útil para ampliar los tipos de una librería.

Una unión (A | B) dice que un valor es de un tipo o de otro. Es muy habitual con tipos literales: type Talla = "S" | "M" | "L" solo admite esos tres textos, y el editor te los autocompleta. También expresa valores que pueden faltar: string | null.

Sobre una unión solo puedes hacer lo que es válido para todos sus miembros. Si id es string | number, no puedes llamar a id.toUpperCase() sin más: primero tienes que comprobar que es un texto. Esa comprobación es el narrowing, que verás a continuación.

El narrowing (estrechamiento) es lo que hace TypeScript cuando lee un if: dentro de if (typeof id === "string") sabe que id es un texto y, en el else, que es el resto de la unión. No es una sintaxis nueva: son comprobaciones de JavaScript que el compilador sigue de cerca.

Las más usadas son typeof para primitivos, in para saber si un objeto tiene una propiedad ("ladrar" in mascota), instanceof para instancias de clases y la comparación con null. Si ninguna basta, puedes escribir tu propia comprobación con un predicado de tipo: una función cuyo tipo de retorno es valor is Tipo.

Una unión discriminada es una unión de objetos que comparten una propiedad con un valor literal distinto en cada uno: el discriminante. Por ejemplo, { estado: "cargando" }, { estado: "ok", datos } y { estado: "error", mensaje }. Al comprobar estado con un if o un switch, TypeScript sabe exactamente qué otras propiedades existen en cada rama.

Es el patrón ideal para modelar estados, porque impide combinaciones imposibles, como tener a la vez datos y un mensaje de error. Y si en el default del switch asignas el valor a una variable de tipo never, TypeScript te avisará cuando alguien añada un caso nuevo y olvide tratarlo.

Un genérico es un tipo que recibe otro tipo como parámetro, entre ángulos: Array<string>, Promise<Usuario>. Tú también puedes escribirlos: function primero<T>(lista: T[]): T | undefined funciona con listas de cualquier cosa y conserva el tipo: si le pasas string[], devuelve string | undefined.

Casi nunca hace falta indicar T al llamar a la función, porque TypeScript lo infiere de los argumentos. Puedes restringirlo con extends, como en <T extends { id: number }>, para exigir que tenga ciertas propiedades. Los genéricos están por todas partes: en los Map, en las promesas, en el tipo de las respuestas de una API.

TypeScript incluye tipos utilitarios que crean un tipo nuevo a partir de otro. Partial<T> hace opcionales todas las propiedades; Pick<T, "a" | "b"> se queda solo con algunas; Omit<T, "id"> quita las que indiques; Record<K, V> describe un objeto con claves de tipo K y valores de tipo V; y ReturnType<typeof f> extrae el tipo que devuelve una función.

La ventaja es que el tipo derivado sigue al original: si mañana añades stock a Producto, Omit<Producto, "id"> lo incluye sin que toques nada. Hay más, como Required, Readonly, Parameters o Awaited.

El tsconfig.json de la raíz del proyecto configura el compilador: qué archivos incluir (include), a qué versión de JavaScript apuntar (target), qué sistema de módulos usar (module) y cómo de estrictas son las comprobaciones. Los frameworks generan uno razonable al crear el proyecto; esta misma app tiene el suyo.

La opción más importante es "strict": true. Activa un grupo de comprobaciones, entre ellas strictNullChecks, que te obliga a tener en cuenta null y undefined, y noImplicitAny, que no deja que un parámetro sin tipo se convierta en any en silencio. Sin strict, TypeScript deja pasar muchos de los errores que justifican usarlo.

tsc es el compilador oficial: comprueba los tipos de todo el proyecto y, si se lo pides, genera los archivos .js. Es exhaustivo, pero lento en proyectos grandes, porque necesita analizar todos los archivos juntos. Con tsc --noEmit solo comprueba, sin generar nada.

Muchas herramientas modernas separan los dos trabajos. esbuild, SWC, bundlers como Vite y, en sus versiones recientes, el propio Node.js hacen type stripping (eliminación de tipos): borran las anotaciones y ejecutan o empaquetan el JavaScript que queda, sin comprobar nada. Por eso son casi instantáneas. La comprobación queda para el editor y para tsc --noEmit en el pipeline de CI.