Cómo Migrar a TypeScript 6.0 y Evitar Problemas
Dominicode¿Listo para dejar de escribir código como si fuera 2016? TypeScript 6.0 no es un parche: es un ultimátum. Lee rápido. Haz el plan. Y no lo dejes para mañana.
Tiempo estimado de lectura: 8 min
- TypeScript 6.0 activa “strict” por defecto y cambia el módulo por defecto a ESM: esto exigirá limpiar deuda técnica y migrar módulos.
- Trae soporte nativo para APIs modernas (Temporal, getOrInsert en Map) que reducen boilerplate y errores de fechas y caches.
- Planifica la migración: branch, activar strict, clasificar errores, pruebas y CI, migración gradual a ESM y reemplazo progresivo de Date por Temporal.
TypeScript 6.0 ya está aquí. Y no viene a hacerte la vida más fácil solo por cortesía: viene a exigir calidad. Si tu repo huele a “any” y a configuraciones por defecto, vas a ver errores. Muchos. Bienvenidos a la criba.
Resumen rápido (lectores con prisa)
TypeScript 6.0 activa “strict” por defecto, cambia el módulo por defecto a ESM y trae typings nativos para APIs modernas como Temporal y utilidades como getOrInsert en Map. Migrar requiere rama dedicada, pruebas y una estrategia gradual para modernizar módulos y reemplazar Date por Temporal.
Qué cambia en TypeScript 6.0
Primero: el golpe que no puedes ignorar — strict por defecto
Hasta ahora, muchos iniciaban proyectos con la mínima fricción posible. Eso se acabó. TS 6.0 crea nuevos proyectos con “strict”: true por defecto. Traducción al cristiano:
- noImplicitAny se vuelve exigente. Si algo no tiene tipo, ahora te lo va a recordar a gritos.
- strictNullChecks hace que ignorar null y undefined sea una mala idea.
- strictBindCallApply valida que cuando cambias el contexto de una función, lo hagas correctamente.
Si tu código vive de aserciones (as any, as unknown, as Tipo), la migración te sacará los esqueletos del armario. Buen momento para limpiar deuda técnica, no para hacer commits de pánico.
Ejemplo rápido: tsconfig mínimo ahora
{
"compilerOptions": {
"target": "ES2022",
"module": "esnext",
"strict": true,
...
}
}
Segundo: adiós CommonJS (por defecto), hola esnext
TS 6.0 asume ESM como estándar. El valor por defecto de module pasa a esnext. Esto es intencional: el mundo ya está usando imports nativos, top-level await y bundlers modernos.
Impactos prácticos:
- Si aún exportas con module.exports y require(), tendrás que migrar o añadir compatibilidad.
- Mejora el tree-shaking en bundlers modernos.
- Usa Top-Level Await sin trucos.
¿Te preocupa Node legacy? Mantén compatibilidad en módulos concretos o transpila a CommonJS solo donde lo necesites. Pero el camino natural ahora es ESM.
Tercero: nuevas API que facilitan la vida (Temporal, getOrInsert…)
Temporal: el reemplazo sensato del desastre llamado Date
Temporal no es una moda. Es la API de fechas que por fin piensa en zonas horarias, mutabilidad y precisión. TS 6.0 trae typings nativos para Temporal, así que puedes usarla sin depender de librerías externas.
Ejemplo:
import { Temporal } from '@js-temporal/polyfill'; // en runtime, o nativo en motores que lo implementen const ahora = Temporal.Now.plainDateTimeISO(); const proximaSemana = ahora.add({ days: 7 }); console.log(proximaSemana.toString());
Temporal hace que calcular intervalos, convertir zonas y sumar días deje de ser una pesadilla llena de bugs.
getOrInsert en Map: menos boilerplate, menos condiciones de carrera
La operación de “si existe devuélvelo, si no cálcula/crea e inserta” es un patrón recurrente. Con getOrInsert (o emplace) lo tienes atómico y tipado:
const cache = new Map<string, Usuario>(); const user = await cache.getOrInsert(id, async () => await fetchUsuario(id));
Esto evita el clásico:
if (!map.has(key)) map.set(key, factory()); const val = map.get(key);
Menos código, menos bugs, menos gente escribiendo race conditions cuando la función es asíncrona.
Cómo migrar sin incendiar el repo (plan paso a paso)
Plan práctico
- 1) No lo hagas en master. Crea un branch de migración y un plan.
- 2) Activa strict localmente: cambia tsconfig y corre tsc. Déjalo fallar.
- 3) Clasifica errores por impacto: trivial (añadir tipo), moderado (cambiar firmas), crítico (bibliotecas externas).
- 4) Prioriza los puntos de entrada: handlers API, parsers de JSON, webhooks, init de app.
- 5) Añade pruebas y CI que compile en strict. Si falla la compilación en PR, no se mergea.
- 6) Moderniza módulos a ESM gradualmente. Empieza por paquetes que usen bundlers modernos.
- 7) Reemplaza Date por Temporal en nuevos módulos. Hazlo con PRs pequeños.
- 8) Introduce getOrInsert para caches y mapas concurridos.
Checklist práctico para cada repo
- – ¿tsconfig tiene “strict”: true? Si no, actívalo en un branch.
- – ¿Import/Export mixto? Documenta y migra módulos uno por uno.
- – ¿Tests unitarios? Asegúrate de que cubran la lógica de frontera (parsers, inputs externos).
- – ¿Variables de entorno y config? Añade validación en startup (Zod o similar).
- – ¿Dependencias nativas de Node? Verifica compatibilidad con ESM o usa interop wrappers.
Riesgos reales y cuándo NO actualizar aún
No es un dogma: hay casos donde deberías esperar.
- – Repos monolíticos con mil paquetes legacy y dependencias dinámicas de require().
- – Librerías que exponen CommonJS exclusivamente y no tienen roadmap de ESM.
- – Pipelines que necesitan latencia ultra-baja y donde cambiar la cadena de build ahora es peligroso.
Si estás en uno de esos escenarios, planifica una migración progresiva y una ventana de compatibilidad.
Performance y el futuro del compilador (spoiler: se viene cambio de motor)
TS 6.0 es la última gran versión mayor que funciona sobre el compilador escrito en JS/TS. El equipo ha dejado claro que la arquitectura actual llegó a su techo en repos masivos, y se ha hablado de explorar compiladores nativos (Go u otras tecnologías). Eso implica:
- – Cambios en la velocidad de análisis a medio plazo.
- – Posibles ajustes en la API del tooling.
- – Mayor exigencia en la calidad del código para aprovechar mejoras de rendimiento.
No lo tomes como alarma: tómalo como señal para ordenar tu base de código ahora, antes de que el motor cambie.
Ejemplos rápidos que deberías probar hoy (copia-pega y juega)
- 1) Activar strict y ver errores:
npx tsc --init # edita tsconfig: "strict": true npx tsc --noEmit
- 2) Probar Temporal (cliente o node con polyfill):
npm i @js-temporal/polyfill node -e "const { Temporal } = require('@js-temporal/polyfill'); console.log(Temporal.Now.plainDateTimeISO().toString());"
- 3) Migrar módulo a ESM:
- cambia exports a export default / named exports - añade "type": "module" en package.json donde aplique
Una metáfora rápida
TS 6.0 es el peaje en la autopista. Si vas en coche viejo sin luces, te obliga a parar y actualizar. Si ya vas con el coche bien afinado, pasas más rápido. Y sí: pagarás por entrar, pero el viaje será más predecible.
Cierre con plan de ataque corto (haz esto hoy)
- 1. En un branch, activa strict y corre tsc. Mira la lista de fallos.
- 2. Arregla los 10 errores más ruidosos. Haz PRs pequeños.
- 3. Actualiza un paquete a ESM y lanza canary.
- 4. Reemplaza Date por Temporal en un módulo pequeño.
- 5. Añade validaciones de entrada (webhooks, APIs) usando Zod o tu validador favorito.
CTA
¿Quieres la checklist automática para tu repo? Respóndeme con “MIGRAR MI REPO” y te envío el script que crea el branch, activa strict y lista los errores más críticos.
FAQ
¿Por qué TS 6.0 activa strict por defecto?
Porque busca elevar la calidad del código desde el inicio de nuevos proyectos. Activar strict reduce errores silenciosos relacionados con any, null y llamadas mal tipadas.
¿Tengo que migrar todo a ESM de inmediato?
No. La recomendación es migrar gradualmente: empuja módulos que ya usan bundlers modernos, mantén compatibilidad para paquetes legacy y transpila a CommonJS solo donde sea imprescindible.
¿Cómo empiezo a usar Temporal sin romper producción?
Introduce Temporal en módulos nuevos o en PRs pequeños. Usa el polyfill @js-temporal/polyfill en entornos que no lo soporten nativamente y añade pruebas para conversiones de zona horaria e intervalos.
¿Qué hago con dependencias que solo expone CommonJS?
Mantén wrappers de interop o transpila esos paquetes en tu pipeline. Prioriza reemplazos si la dependencia es crítica y no tiene roadmap hacia ESM.
¿Qué pruebas debo priorizar durante la migración?
Prioriza tests sobre parsers de entrada, handlers de API, webhooks y cualquier lógica que deserialice datos externos. Asegura que el CI falle si TypeScript en strict da errores.
¿Cómo evitar que un cambio de tsconfig rompa CI?
Haz la activación de strict en un branch con su propio pipeline, clasifica errores y crea PRs pequeños que corrigen grupos de errores. No merges hasta que el build en strict pase.