TypeScript
Explica cómo TypeScript comprueba tipos, transforma archivos y separa el análisis estático del comportamiento que finalmente ejecuta JavaScript.
El compilador de TypeScript puede analizar tipos y también producir JavaScript. Son responsabilidades relacionadas, pero no son lo mismo.
archivo .ts
↓ parsear
estructura del programa
↓ enlazar nombres
símbolos y scopes
↓ comprobar tipos
diagnósticos
↓ emitir, si corresponde
JavaScript + declarations + source mapsEl parser comprueba que la sintaxis pueda convertirse en una estructura válida.
const value = ;Este código no puede analizarse correctamente y produce un error de sintaxis antes de discutir tipos.
const price = 100;
console.log(prcie);El compilador necesita relacionar cada identificador con su declaración. prcie no existe dentro de los scopes visibles.
const price = 100;
price.toUpperCase();La sintaxis es válida, pero la operación no pertenece al tipo inferido.
const price: number = 100;Puede producir:
const price = 100;La anotación desaparece.
npx tsc --noEmitEs común en proyectos donde Vite, Next.js, esbuild, SWC u otra herramienta transforma el código.
tsc → comprobar tipos
bundler/framework → transformar, empaquetar y servirEvita asumir que tsc siempre es quien construye el JavaScript final.
npx tsc -p tsconfig.json --noEmit-p indica qué proyecto comprobar. Ejecutar tsc con archivos sueltos puede utilizar reglas distintas o ignorar la configuración, según la versión y el comando empleado.
Para un repositorio real, comprueba el proyecto, no un archivo aislado con defaults accidentales.
Según la configuración, TypeScript puede emitir JavaScript aunque existan errores.
{
"compilerOptions": {
"noEmitOnError": true
}
}En un proyecto con bundler y noEmit, la build debe ejecutar el typecheck como paso obligatorio; de lo contrario, otra herramienta puede generar output aunque tsc nunca haya comprobado el código.
Estas construcciones normalmente no existen en runtime:
interface Product {
id: string;
}
type ProductId = string;
function findProduct(id: ProductId): Product | null {
return null;
}El runtime recibe funciones y valores de JavaScript, no interface ni type.
Algunas características de TypeScript sí generan o modifican JavaScript:
enum Status {
Active,
Disabled,
}También pueden emitir código:
No todas las construcciones de TypeScript son comentarios borrables.
{
"compilerOptions": {
"target": "ES2022"
}
}target comunica qué versión aproximada de sintaxis JavaScript puede recibir el entorno final.
TypeScript puede transformar algunas características:
const name = user?.profile?.name;pero no añade automáticamente APIs ausentes como fetch, structuredClone o Promise.
{
"compilerOptions": {
"lib": ["ES2022", "DOM"]
}
}lib controla qué declaraciones globales conoce el checker.
Añadir DOM hace que TypeScript conozca window y document; no crea un navegador dentro de Node.js.
tipo disponible ≠ API disponible en runtimeconst product = value as Product;as afecta al checker. No inserta una validación ni cambia el objeto.
input.value!.trim();El ! también desaparece. Si value es realmente null o undefined, JavaScript falla normalmente.
declare const configuration: Configuration;Promete que el valor existirá en runtime, pero no lo crea.
Si la promesa es falsa:
TypeScript: sin error
JavaScript: ReferenceErrorUna librería puede producir archivos .d.ts:
{
"compilerOptions": {
"declaration": true
}
}Los declarations describen la API pública para otros proyectos, pero no contienen la implementación ejecutable.
{
"compilerOptions": {
"sourceMap": true
}
}Relacionan el JavaScript emitido con el TypeScript original para debugging. La herramienta que finalmente transforma el código también debe conservar correctamente esa cadena.
npx tsc --noEmit
vite buildnpx tsc -p tsconfig.build.json
→ JavaScript
→ .d.ts
→ source mapsLa configuración depende del producto que estás entregando.
as o ! validan.tsc --noEmit comprueba sin producir JavaScript.target controla transformación de sintaxis.lib controla declaraciones conocidas, no capacidades reales.declare son promesas al checker.¿Por qué añadir "DOM" a lib no permite utilizar document dentro de un proceso Node.js?
Porque lib solo añade las declaraciones que usa el checker. El runtime continúa siendo Node.js y no crea las APIs de una ventana del navegador.
Proyecto TypeScript y tsconfig.json convierte estas decisiones en una configuración explícita.