5.1Node.js con TypeScript
Lo esencial en 30 segundos
- TS = JS + tipos : superconjunto de JavaScript — todo JS válido es TS válido, se añade el tipado estático por encima.
- Errores antes de la ejecución : el compilador verifica los tipos y detecta toda una categoría de errores en la compilación, no en producción.
- Herramientas y equipo : autocompletado preciso, refactorización segura, código que se documenta solo — decisivo en proyectos serios.
Mini-caso hilado — Salim tipa su API en Argel
Salim, desarrollador junior en Argel, mantiene una pequeña API de seguimiento de pedidos : un campo « cantidad » llega a veces como texto, un nombre de propiedad mal escrito hace fallar una ruta en producción. Introduce TypeScript progresivamente : anota sus funciones, define una interfaz para sus datos, deja que el compilador detecte las incoherencias antes de la ejecución. Esta sección cuenta su cambio — y el hilo continúa en 5.2, 5.3 y 5.4.
Este mismo caso vuelve en el curso, el esquema, el guion y el reto 48h — y continúa en 5.2, 5.3 y 5.4.
1. Un superconjunto tipado
TypeScript es un superconjunto de JavaScript que añade el tipado estático : todo JavaScript válido es TypeScript válido, los tipos se declaran por encima (let age: number, function f(nom: string): string). TypeScript verifica la coherencia ANTES de la ejecución (en la compilación) y detecta errores que JavaScript, con tipado dinámico, solo revelaría en runtime : tipo incompatible, propiedad inexistente, argumento faltante. Salim conserva todo su JavaScript — con una red de seguridad añadida.
La regla de orden : JavaScript primero, tipos por encima. Solo se tipa bien lo que se comprende : los tipos describen estructuras y funciones JavaScript ya dominadas. Salim consolida su JS (nivel 1) y luego anota.
2. Compilación y beneficios
TypeScript no se ejecuta directamente : se compila a JavaScript ordinario (archivos .ts → .js vía tsc, configurado por tsconfig.json ; ts-node lo ejecuta en desarrollo). Beneficios : detección de errores en la compilación, autocompletado y herramientas superiores en el editor, documentación implícita (los tipos describen el código), robustez y mantenibilidad en proyectos grandes y en equipo. Salim refactoriza sin miedo : el compilador señala lo que se rompe en otro lado.
Casi estándar en Node profesional, excelente con herramientas modernas tipadas (Prisma, Zod). El coste existe — aprendizaje del sistema de tipos, etapa de compilación, algo de verbosidad reducida por la inferencia — pero en una aplicación seria, el cálculo es ampliamente favorable.
3. Progresivo, no todo o nada
TypeScript se aprende progresivamente : tipado ligero al inicio (anotaciones simples), interfaces y tipos avanzados después. La inferencia adivina a menudo los tipos sin escribirlos — no hace falta anotarlo todo. Para un pequeño script desechable, JavaScript puro basta ; para una aplicación que crece, dura o se hace en equipo, TypeScript vale el esfuerzo. Salim empieza tipando sus estructuras de datos (un tipo Pedido) y sus retornos de funciones.
A evitar : aprender TypeScript sin una base sólida de JavaScript (dos aprendizajes mezclados), o forzar el tipado estricto en todas partes desde el primer día. El buen ritmo : anotar lo esencial, dejar que la inferencia haga el resto, endurecer después.
🔎 Ejemplo concreto — Salim detecta un error antes de producción
Error de tipo detectado en la compilación.
interface Commande { article: string; quantite: number; }
function total(c: Commande): number {
return c.quantite * 2;
}
total({ article: 'câble', quantite: '3' });
// ❌ TS : 'quantite' debe ser number — detectado ANTES de la ejecuciónLectura : en JavaScript puro, el error solo aparece en runtime — incluso en producción.
Lección : toda una categoría de errores eliminada mientras se programa.
Vocabulario de la sección
- TypeScript
- Superconjunto de JavaScript que añade el tipado estático ; se compila a JS ordinario.
Ejemplo sencillo: Salim tipa su API de pedidos en Argel sin reescribir su lógica.
Lo que no es: un lenguaje distinto que habría que aprender aparte.
Reflejo: ¿mi JS ya funciona? añado los tipos por encima.
- Tipado estático
- Tipos declarados y verificados antes de la ejecución, en la compilación.
Ejemplo sencillo: Una cantidad como texto se señala antes de todo despliegue.
Lo que no es: una verificación que solo tendría lugar en runtime.
Reflejo: ¿este error sería visible antes de producción?
- Compilación (tsc)
- El compilador verifica los tipos y luego transforma los .ts en .js.
Ejemplo sencillo: Salim lanza tsc : cero errores, el .js se genera.
Lo que no es: una ejecución directa del .ts por Node sin etapa.
Reflejo: ¿tsconfig.json ajustado antes de compilar?
- Inferencia
- TypeScript adivina a menudo los tipos sin anotación explícita.
Ejemplo sencillo: Salim no anota cada variable local, TS las deduce.
Lo que no es: la obligación de anotarlo todo en todas partes.
Reflejo: ¿este tipo necesita escribirse, o ya se adivina?
- Adopción progresiva
- Tipado ligero primero, tipos avanzados después, reutilizando su JS.
Ejemplo sencillo: Salim tipa sus estructuras y luego endurece con las semanas.
Lo que no es: tiparlo todo en estricto desde el primer día.
Reflejo: ¿cuál es el tipado útil más pequeño esta semana?
En la práctica — Tipar su back-end con TypeScript
- Configure un proyecto TypeScript (tsconfig.json) y ejecute .ts en desarrollo (ts-node o soporte nativo).
- Anote tipos : variables (`let age: number`), parámetros y retornos de funciones (`function f(x: string): number`).
- Compruebe la detección de errores en la compilación : pase un tipo incorrecto, acceda a una propiedad inexistente — TypeScript le avisa ANTES de la ejecución.
- Disfrute el autocompletado y las herramientas en VS Code ; introduzca interfaces/tipos para sus estructuras de datos (p. ej. un tipo Pedido).
Guion listo para decir — proponer TypeScript al equipo
« En nuestra API en Argel, propongo introducir TypeScript progresivamente : conservamos nuestro JavaScript, anotamos nuestras estructuras y nuestras funciones, y el compilador detectará los errores de tipos antes de producción. Empezamos ligero — interfaces y firmas — y endurecemos después. Objetivo : menos fallos en runtime y un código más legible en equipo. »
Para decir en reunión de equipo para hacer adoptar el tipado por etapas, sin prometer una migración total inmediata.
Modelo copiar-pegar — base tsconfig.json
TS — BASE DEL PROYECTO
{
"compilerOptions": {
"target": "ES2022",
"module": "commonjs",
"outDir": "dist",
"strict": true,
"esModuleInterop": true,
"skipLibCheck": true
},
"include": ["src/**/*"]
}
COMANDOS : npx tsc --init (generar) · npx tsc --noEmit (verificar) · npx tsc (compilar hacia dist)Solo / presupuesto pequeño
Salim solo : un tsconfig básico + anotaciones en las estructuras críticas basta — verificar con tsc antes de cada despliegue.
Pyme / equipo reducido
Tipar primero las firmas compartidas (API, modelos) : ahí nacen los errores de integración.
Pyme en Argel
Salim coordina el paso a TypeScript con el equipo en Argel : primero los archivos nuevos en .ts, migración del resto sobre la marcha.
Equipo que empieza
Pareja : uno escribe el JS, el otro añade las interfaces ; revisión cruzada de los tipos antes de cada fusión.
✓ Buenas prácticas
- Aprender TS progresivamente (tipado básico, luego interfaces y genéricos).
- Reutilizar su JavaScript (TS = JS + tipos).
- Adoptar TypeScript en proyectos serios (robustez, herramientas, equipo).
✗ Errores frecuentes
- Aprender TS sin una base sólida de JavaScript (solo se tipa bien lo que se comprende).
- Forzar TypeScript en un pequeño script desechable (excesivo).
- Ignorar la inferencia y sobreanotar lo que TS ya adivina.
Puntos clave
- TypeScript = superconjunto de JavaScript que añade el TIPADO ESTÁTICO (todo JS válido es TS válido) ; se COMPILA a JS ordinario.
- Tipado ESTÁTICO (TS) : tipos verificados ANTES de la ejecución → detecta una categoría de errores pronto (frente a JS dinámico, errores en runtime).
- Beneficios : detección de errores en la compilación, AUTOCOMPLETADO/herramientas superiores, documentación implícita, robustez y mantenibilidad.
- Casi estándar en Node profesional ; excelente con herramientas modernas (Prisma, Zod tipados). Se aprende progresivamente ; el dominio de JS se reutiliza.
Reto 48h — aplica mañana
Tome 1 función de su API y escriba su interfaz + su firma tipada : ¿el compilador detecta una incoherencia que Salim habría pasado por alto?
- Puedo explicar TS = JS + tipos en una frase.
- Mi función está tipada (interfaz + firma) y verificada.
- Sé cuándo basta JS puro y cuándo se impone TS.
Preguntas frecuentes
¿Vale TypeScript el esfuerzo adicional frente a JavaScript?
Para la mayoría de los proyectos serios, sí — la adopción masiva de la industria lo confirma. Coste : aprendizaje del sistema de tipos, etapa de compilación, algo de verbosidad (reducida por la inferencia). Beneficios : errores detectados en la compilación (tipos incompatibles, propiedades inexistentes, erratas — que en JS solo aparecerían en runtime, incluso en producción), herramientas superiores (autocompletado, navegación, refactorización segura — una ganancia diaria), robustez y confianza, mantenibilidad en equipo, excelente ecosistema (Prisma, Zod). Para un pequeño script desechable, JavaScript puro basta ; para una aplicación seria, TypeScript vale ampliamente el esfuerzo.
¿Hay que aprender JavaScript a fondo ANTES de TypeScript, o ambos juntos?
Hace falta una buena base de JavaScript ANTES de aprovechar TypeScript, porque TS = JS + tipos : solo se tipa bien lo que se comprende. Aprenda los fundamentos (async/await, módulos, objetos) en JavaScript puro, construya cosas en JS, luego introduzca TypeScript cuando JS resulte cómodo — el aprendizaje de TS se vuelve entonces digerible (el sistema de tipos, no todo el lenguaje). No hace falta ser experto absoluto antes de TS, pero no mezcle ambos aprendizajes desde el inicio.
¿Qué aporta TypeScript frente a JavaScript?