Category: TypeScript

¿Quieres que tus tipos de TypeScript hagan el trabajo sucio por ti —y de verdad— en vez de darte una falsa sensación de seguridad?

Tiempo estimado de lectura: 4 min

• Los tipos condicionales (T extends U ? X : Y) se evalúan en tiempo de compilación y permiten metaprogramación robusta.
• infer captura partes de tipos para extraer retornos, parámetros y elementos internos sin runtime.
• Patrones clave: Unwrap para Promises, evitar distribución con tuplas, manipular tuples con Head/Tail, y extraer retornos async.
• Precauciones: complejidad excesiva, deuda técnica y necesidad de validación runtime para datos externos.

Bien. Aquí tienes una guía práctica que no promete magia, pero sí te salva de la gimnasia de tipos inútil y de bugs que aparecen a las 2AM.

Resumen rápido (lectores con prisa)

Los condicionales de tipos son ternarios que TypeScript evalúa en tiempo de compilación. infer permite extraer partes de un tipo coincidente. Úsalos para utilidades tipo-level (Unwrap, AsyncReturn, Head/Tail) y evita su abuso: documenta, limita y combina con validación runtime cuando el input viene de la red.

Introducción

Primero, lo obvio: el condicional de tipos es un ternario que vive en el compilador. Sintaxis: T extends U ? X : Y. Se evalúa en tiempo de compilación. No en runtime. Eso lo convierte en una espada afilada: poderosa, pero cortante.

Condicionales de tipos

Sintaxis

Sintaxis: T extends U ? X : Y. Se evalúa en tiempo de compilación.

Ejemplo mínimo

type IsString<T> = T extends string ? true : false;
type A = IsString<'hola'>; // true
type B = IsString<42>;     // false

Sencillo. Útil para construir utilidades.

infer

Qué es

infer captura piezas del tipo que estás inspeccionando. Es la manera de decirle a TS: “si esto encaja, arráncame esto otro”.

Ejemplo clásico — extraer el tipo de retorno

type MyReturn<T> = T extends (...args: any[]) => infer R ? R : never;
type Fn = () => { id: number };
type R = MyReturn<Fn>; // { id: number }

Útil. Limpio. Poderoso.

Patrones

Patrón 1 — Unwrap de Promises (recursivo)

Cuando trabajas con APIs, las promesas anidadas son una plaga. Esto te limpia el resultado:

type Unwrap<T> = T extends Promise<infer U> ? Unwrap<U> : T;
type X = Unwrap<Promise<Promise<{ ok: true }>>>; // { ok: true }

Patrón 2 — Tipos distributivos y el problema que nadie lee

Si T es una unión, el condicional se aplica a cada miembro (distribuye). A veces quieres eso. A veces no.

Distribución:

type ExcludeFunc<T> = T extends Function ? never : T;
type U = ExcludeFunc<string | (() => void)>; // string

Evitar distribución

Envuélvelo en una tupla.

type NoDist<T> = [T] extends [Function] ? never : T;

Memorízalo. Te salvará de errores raros.

Patrón 3 — Extraer elementos de tuples/arrays

infer también domina tuplas. Necesitas sacar head/tail o el último elemento:

type Head<T extends any[]> = T extends [infer H, ...any[]] ? H : never;
type Tail<T extends any[]> = T extends [any, ...infer R] ? R : never;

Esto abre puertas para manipulaciones tipo-level sin hacer trampas.

Patrón 4 — AsyncReturnType para funciones async

type AsyncReturn<T> = T extends (...args: any[]) => Promise<infer R> ? R : never;

Ideal para tipos de efectos y sagas.

Casos reales donde esto brilla

• Clientes HTTP tipados por endpoint (súper seguro, sin as adivinatorio).
• Librerías que exponen utilidades genéricas robustas.
• Metaprogramación de APIs internas (mapea rutas a tipos de response).
• Sistemas de validación y mapeo que dependen de signatures de funciones.

Ejemplo rápido: tipos por endpoint

interface Endpoints {
  '/users': { id: string, name: string }[];
  '/status': { ok: boolean };
}

function fetchApi<T extends keyof Endpoints>(url: T): Promise<Endpoints[T]> {
  return fetch(url).then(r => r.json());
}

No más any. No más guessing.

Pitfalls — Lo que te rompe la vida si no tienes cuidado

• Complexity blowup: tipos gigantes ralentizan el compilador. TS puede confundirse y tirar errores crípticos.
• Abuso: si tu equipo no entiende, se convierte en deuda técnica invisible.
• Debug hard: errores en tipos a veces son opacos; documenta y divide tipos largos.
• Runtime vs compile-time: los tipos no validan data externa. Para eso, runtime schemas (Zod) son tus amigos.

Buenas prácticas — rápido y aplicable

• Usa tipos condicionales en librerías y núcleos infra. No en cada componente.
• Nombra aliases: type AsyncReturn<T> = ... — no pongas 10 ternarios directos.
• Comenta. Sí, los tipos necesitan comentarios.
• Mantén límites: si un tipo tiene más de 30–40 líneas, replantea.
• Combina con validación runtime donde el input viene de la red.
• Testea tipos con tsd o expect-type para evitar regresiones.

Trucos avanzados en dos líneas

• Forzar no-distribución: [T] extends [U] ? X : Y.
• Obtener parámetros de una función: type Params<T> = T extends (...a: infer A) => any ? A : never;
• Extraer propiedades no-función: usa mapped types con condicionales para filtrar claves.

Metáfora rápida para que no lo olvides

Los tipos condicionales son el sistema inmunitario del código. Te protegen si los pones en el lugar correcto. Si los usas por todos lados sin control, te provocan una reacción autoinmune: complejidad que te derriba.

¿Quieres algo práctico que puedas pegar ya?

Puedo mandarte:

• Un cheat-sheet con 25 utilidades (Unwrap, AsyncReturn, Head, Tail, PickByValue, etc.).
• Un pequeño repo con ejemplos y tests de tsd.
• Un snippet para un cliente HTTP tipado por endpoints + validación Zod integrada.

Responde “Envíame el cheat-sheet” y te lo paso listo para copiar. No es teoría. Es la diferencia entre escribir tipos y dejar que los tipos te salven. Esto no acaba aquí.

FAQ

• ¿Qué es un condicional de tipos en TypeScript?
• ¿Qué hace infer?
• ¿Cómo evito que un condicional distribuya sobre una unión?
• ¿Los tipos garantizan que los datos externos sean válidos?
• ¿Cuándo debo usar estos patrones vs validación runtime?
• ¿Qué herramientas recomiendas para testear tipos?

TypeScript 7.0 en Go: qué está pasando y por qué es histórico

Tiempo estimado de lectura: 3 min

• Reescritura en Go: Microsoft está migrando el compilador oficial de TypeScript a Go, buscando binarios nativos, paralelismo real y un GC con latencias más predecibles.
• Rendimiento práctico: Benchmarks internos muestran mejoras de orden de magnitud que reducen compilaciones de minutos a segundos, con impacto directo en CI/CD y experiencia de editor.
• Compatibilidad y fricción: Integraciones que consumen la API interna de tsc requerirán adaptación (RPC, bindings, WASM) y pruebas exhaustivas en casos límite.
• Acción inmediata: Estabilizar en TypeScript 6.0, automatizar chequeos de tipos en CI y mapear dependencias que usan la API interna de tsc.

Tabla de contenidos

• TypeScript 7.0 en Go: qué está pasando y por qué es histórico
• Introducción
• Resumen rápido (lectores con prisa)
• TypeScript 7.0 en Go: qué está pasando y por qué es histórico (resumen técnico)
• Por qué importa para proyectos grandes y monorepos
• Impacto en Angular y React: matices prácticos
• Impacto — Angular
• Impacto — React/Next.js/Vite
• Riesgos y fricciones en el ecosistema
• Qué hacer hoy: plan de preparación para equipos técnicos
• Perspectiva: por qué es histórico
• Fuentes y lecturas
• FAQ

TypeScript 7.0 en Go: qué está pasando y por qué es histórico — la frase debería ser familiar para cualquier Tech Lead que haya sufrido compilaciones lentas en monorepos. Microsoft está reescribiendo el compilador de TypeScript en Go, un movimiento que cambia la base de rendimiento y operacionalidad de todo el ecosistema. Esto no es una mejora incremental: es una rearquitectura que hace viable un análisis tipo‑a‑gran escala sin renunciar a la precisión semántica que define a TypeScript.

Resumen rápido (lectores con prisa)

TypeScript 7.0 es la reescritura del compilador oficial en Go, orientada a rendimiento y paralelismo. Ofrece binarios nativos, mejor paralelización y un GC con latencias más predecibles. Es relevante para monorepos, CI y experiencia de editor. Prepara la migración estabilizando en TypeScript 6.0 y automatizando chequeos de tipos en CI.

TypeScript 7.0 en Go: qué está pasando y por qué es histórico (resumen técnico)

El compilador actual está escrito en TypeScript y corre sobre Node/V8. Esa decisión fue pragmática en 2012, pero hoy limita la paralelización y sufre del JIT/GC de V8 en cargas largas. Reescribir tsc en Go aporta tres ventajas concretas:

• Binarios nativos sin warm‑up de JIT.
• Paralelismo real con goroutines y memoria compartida para analizar módulos en paralelo.
• Un GC con latencias más predecibles, mejorando la experiencia de tsserver.

Las herramientas que demostraron el valor del código nativo ya probaron que compilar fuera de Node puede multiplicar la velocidad. SWC, esbuild, Biome y Turbopack ya marcaron esa tendencia. Ahora el compilador oficial entra en esa categoría, pero manteniendo la verificación de tipos completa que esas herramientas no cubren.

Por qué importa para proyectos grandes y monorepos

Los beneficios no son teóricos. Microsoft reporta mejoras de orden de magnitud en benchmarks internos, reduciendo compilaciones que tardaban minutos a segundos. Traducido a la vida real:

• CI/CD: menos minutos por ejecución ⇒ menos coste y despliegues más rápidos.
• tsserver: indexado y respuestas en el editor que no degradan con el tiempo.
• Compilaciones incrementales: casi instantáneas en repositorios con cientos de paquetes.

Si tu pipeline actual dedica gran parte del tiempo a tsc --noEmit, esto cambia la economía del desarrollo.

Impacto en Angular y React: matices prácticos

Angular

Angular está fuertemente integrado con el pipeline de TypeScript (Angular Compiler y Language Service). Proyectos enterprise con workspaces (Nx, monorepos) verán una mejora directa en ng build, ng serve y en la reactividad de las herramientas de plantilla.

React/Next.js/Vite

La cadena de transpilación de React/Next.js/Vite ya utiliza SWC o esbuild para velocidad, pero sigue ejecutando tsc para verificación de tipos en CI. Ahí la ganancia será ostensible: los chequeos de tipos dejarán de ser el cuello de botella de los pipelines.

En ambos casos, el resultado es práctico: menos tiempo en loops edit→build→test y más capacidad para ejecutar validaciones costosas (análisis estático adicional) sin penalizar al equipo.

Riesgos y fricciones en el ecosistema

El cambio es histórico, no indoloro. Puntos a vigilar:

• Herramientas que consumen la API del compilador (por ejemplo ts-morph) necesitarán adaptaciones para interoperar con el nuevo binario o exponer puentes (RPC, bindings, WASM).
• Integraciones internas que dependen de detalles de implementación de tsc pueden requerir trabajo de migración.
• Compatibility testing: aunque el lenguaje no debería cambiar, diferencias sutiles en corner cases exigen pruebas exhaustivas.

La recomendación es seguir la guía oficial del repositorio de TypeScript y monitorizar los anuncios de Microsoft para migraciones y tooling.

Qué hacer hoy: plan de preparación para equipos técnicos

1. Estabiliza tu base de código en TypeScript 6.0: activa strict: true y corrige errores. TypeScript 6.0 actúa como puente hacia 7.0.
2. Automatiza chequeos de tipos en CI: ejecuta tsc --noEmit y añade cobertura para casos límite de tipos.
3. Identifica dependencias: detecta librerías y herramientas que usan la API interna de tsc y marca tickets de migración.
4. Mide: registra tiempos actuales de compilación y coste de CI para cuantificar mejoras futuras.
5. Mantén pruebas: pruebas end‑to‑end y contract tests; cualquier cambio del compilador debe validar el comportamiento real del producto.

Perspectiva: por qué es histórico

La convergencia de herramientas nativas (Rust/Go) con el ecosistema JavaScript es una tendencia clara: mayor velocidad sin perder integridad semántica. TypeScript 7.0 no es solo rendimiento; es la posibilidad de escalar el análisis estático a organizaciones enteras sin sacrificar productividad. Para equipos que priorizan calidad y velocidad operativa, esto reconfigura las decisiones de arquitectura y la inversión en tipado.

Fuentes y lecturas

• TypeScript (repositorio oficial)
• SWC
• esbuild
• Biome
• Turbopack
• ts-morph

Adoptar TypeScript 6.0 y preparar tu infraestructura ahora es la mejor forma de capitalizar la promesa de TypeScript 7.0 en Go cuando el binario esté listo para producción.

FAQ

• ¿Qué cambia exactamente al reescribir tsc en Go?
• ¿Debo migrar mis repositorios ahora mismo?
• ¿Cómo afectará esto a mi CI/CD?
• ¿Qué pasa con herramientas que usan la API de tsc?
• ¿Cambiará el lenguaje TypeScript?
• ¿Cómo puedo medir el beneficio esperado?

¿Te fiarías de un mensaje de WhatsApp para pagar una factura importante? No. Entonces, ¿por qué confías en que la red te devuelva exactamente el JSON que tu UI necesita?

Poca gente lo dice tan claro: la red es hostil. Los backends cambian, las APIs se versionan mal y los datos llegan raros. TypeScript te da sensaciones de seguridad en el editor. Fuera de la compilación, la realidad es JavaScript indiferente. Tipar una API REST no es cuestión de estética. Es la barrera que separa una app que sobrevive a la producción de un desastre nocturno.

Voy a contarte cómo tipar correctamente una API REST en TypeScript sin postureo. Con ejemplos prácticos, decisiones arquitectónicas y la única verdad que importa: que tu app no rompa en prod por culpa de un campo faltante.

Primera regla: el contrato no es el código. Es la promesa. Y debe ser verificable.

Resumen rápido (lectores con prisa)

Qué es: Validar y tipar el JSON recibido de la red en tiempo de ejecución usando esquemas (por ejemplo Zod) junto a tipos TypeScript.

Cuándo usarlo: Siempre en boundaries de red; imprescindible para APIs externas o equipos distintos.

Por qué importa: Previene errores silenciosos en producción y permite estrategias de error diferenciadas.

Cómo funciona: Fetch/axios → recibir unknown → parse con Zod (o similar) → mapear a modelos internos.

¿Por qué los tipos por sí solos no bastan?

TypeScript vive en tiempo de compilación. Cuando haces fetch o llamas a Axios, recibes JSON en tiempo de ejecución. TypeScript no inspecciona la red. Usar as T es firmar un cheque sin fondos: le estás diciendo al compilador “confía en mí”, pero nadie te va a confiar cuando el objeto tenga un null donde esperabas string.

Eso genera errores silenciosos: undefined que se propaga, componentes que se caen sin stack trace claro, tests que pasan porque los mocks también mienten. La alternativa no es renunciar a TypeScript. Es complementarlo con validación runtime donde pinte.

Paso 1 — Define el contrato: DTO claro y aislado

Haz DTOs en su propio archivo. Separa lo que viene de la red de tus modelos internos.

Ejemplo:

// api/types.ts
export interface UserResponse {
  id: string;
  email: string;
  full_name: string; // nota: formato snake_case típico de backend
  created_at: string;
}

export interface ApiError {
  statusCode: number;
  message: string;
  errorCode?: string;
}

¿Por qué aislarlo?

Porque si el backend cambia full_name → fullName, no quieres que todo tu frontend explote. Cambias la capa de red y mapping. Punto.

Paso 2 — Wrappers: encapsula fetch/axios

No llames fetch o axios.get en mitad del componente. Haz un wrapper que:

• haga la petición,
• valide el payload,
• normalice nombres,
• lance errores tipados.

Con fetch:

async function fetchTyped(url: string, opts?: RequestInit): Promise {
  const res = await fetch(url, opts);
  const text = await res.text();
  let json;
  try {
    json = text ? JSON.parse(text) : {};
  } catch {
    throw new Error(`Invalid JSON from ${url}`);
  }
  if (!res.ok) throw Object.assign(new Error('HTTP error'), { status: res.status, body: json });
  return json as T; // todavía una aserción: complementa con validación runtime
}

Con Axios es más limpio:

import axios from 'axios';
async function get(url: string) {
  const res = await axios.get(url);
  return res.data;
}

Pero cuidado: Axios con genéricos es cómodo, no mágico. Sigue siendo una promesa de que la red devolverá lo que dijiste.

Paso 3 — Validación runtime: Zod o similar

Aquí se separan los novatos de los equipos que sobreviven. Zod no es moda; es la última capa de defensa. Define un esquema, parsea el JSON y obtienes tipado estático y validación a la vez.

Ejemplo con Zod:

import { z } from 'zod';

const UserSchema = z.object({
  id: z.string(),
  email: z.string().email(),
  full_name: z.string(),
  created_at: z.string(), // luego puedes transformar a Date si quieres
});

type UserResponse = z.infer<typeof UserSchema>;

async function fetchUser(id: string) {
  const raw = await fetchTyped<unknown>(`/api/users/${id}`);
  return UserSchema.parse(raw); // lanza un error si no coincide
}

Ventajas:

• Detectas inmediatamente datos corruptos.
• Los errores llegan con contexto (qué llave falló y por qué).
• Puedes transformar created_at a Date de forma declarativa.

Paso 4 — Manejo de errores tipados

No uses catch (e) { console.error(e) }. En TS moderno el error es unknown. Te obliga a respirar antes de leer.

Con Axios:

try {
  const u = await get<UserResponse>('/api/users/1');
} catch (err) {
  if (axios.isAxiosError(err)) {
    const server: ApiError | undefined = err.response?.data;
    console.error('Server:', server?.message ?? err.message);
  } else if (err instanceof z.ZodError) {
    console.error('Validation failed:', err.errors);
  } else if (err instanceof Error) {
    console.error('Network or runtime:', err.message);
  } else {
    console.error('Unknown error', err);
  }
}

¿Por qué esto importa?

Porque no es lo mismo que falles por validación (mal payload) que por HTTP 500 o por timeout. Cada caso requiere una estrategia distinta: retry, fallback UI, mostrar mensaje al usuario, reportar a Sentry con tags distintos.

Paso 5 — Normaliza y mapea en la capa de red

No dejes snake_case pululando por la app. Tradúcelo en la capa de consumo.

function mapUser(api: UserResponse) {
  return {
    id: api.id,
    email: api.email,
    fullName: api.full_name,
    createdAt: new Date(api.created_at),
  };
}

Así tus modelos internos usan camelCase y Date real, no strings sucios.

Decisiones arquitectónicas: cuándo validar y cuánto validar

• Si controlas backend y frontend (monorepo o contrato firme): validación runtime puede ser ligera o incluso obviada en puntos internos. Pero en los boundaries externos, sigue validando.
• Si consumes APIs públicas o equipos distintos: valida TODO. Sin excusas.
• Campos opcionales: define qué hacer cuando faltan. ¿Default? ¿Error? No improvises en el handler.

Performance y coste: ¿La validación runtime es lenta?

Sí, agrega CPU. No, no es un killer. Para la mayoría de apps es insignificante comparado con network. Si tu app maneja miles de respuestas por segundo, shardea validaciones o valida en capas: sólo validar payloads que entren a la lógica crítica.

Testing: no te olvides de tests de integración

Mocks unitarios son útiles, pero añade tests e2e que disparen la API real (o un sandbox) y verifiquen que las validaciones y mappings no rompen. Testear tipado estático no te salva si la red cambia; testear contra endpoint sí.

Checklist práctico (aplicable hoy)

1. Centraliza DTOs en src/api/types.ts.
2. Implementa un http wrapper (fetch/axios) que devuelva unknown.
3. Define Zod schemas para cada DTO.
4. Parsea el unknown con los schemas antes de castear a tipos.
5. Mappea a modelos internos (camelCase, Date).
6. Trata y tipa errores (Axios ZodError, Error genérico).
7. Agrega tests e2e para validar contratos.
8. Logea y reporta fallos con contexto (payload, endpoint, user id).

Antipatrones que debes romper hoy

• Usar as T en todo el código. Es la tapa del inodoro para ignorar problemas.
• Confiar en que “el backend no cambia porque somos amigos”.
• No versionar tus contratos. Versiona APIs y mantén backwards compatibility.
• Manejar errores con any. Eso borra información útil para debugging.

Metáfora que funciona: el contrato es la arquitectura del puente

Tu frontend es el tráfico. El backend es el río. Si el puente (contrato) no es firme y verificado, los coches caen al agua. Los tipos son el plano; la validación runtime es el inspector que revisa la soldadura antes de poner el primer coche encima.

Mini-guía de migración si tienes legado

• Prioriza endpoints críticos: pagos, auth, guardar datos de usuario. Valida primero allí.
• Añade schemas Zod incrementales; empieza por parse y logea sin bloquear; luego, cuando el tráfico confirme estabilidad, cambia a bloquear y fallar fast.
• Automatiza alerts: si un endpoint empieza a fallar por validación, dispara una tarea de mesa de ayuda y un PR para el backend. No lo ignores.

Y ahora, lo que pocas hojas blancas te dirán: la cultura importa

La técnica sola no arregla nada. Si los desarrolladores creen que validar es “trabajo extra” y no “seguridad mínima”, la herramienta se convertirá en una carpeta más del repo. Hazlo obligatorio en el CI:

• Test de contractos: correr zod.parse en un job.
• Rechazar PRs si los contratos no están actualizados.
• Mantén el mapping y los schemas en la misma PR que cambia el backend si controlas ambos.

¿Quieres algo listo para copiar y pegar?

Tengo un template completo: wrapper http (fetch + manejo de errores), ejemplo de schema Zod, mapping y un job de GitHub Actions que valida contratos en CI. Lo dejo preparado para TypeScript + React (Vite) o Next.js.

Haz esto ahora:

1. Crea src/api/
2. Pega el wrapper y el schema Zod del template.
3. Añade ci/validate-contracts.yml a tu pipeline.
4. Corre pnpm test:contracts en tu CI.

¿Te lo mando ya?

Responde “Mándame el template” y te paso:

• El wrapper http.ts listo.
• Un user.schema.ts con Zod y z.infer.
• Un ejemplo de fetchUser + mapping + test e2e.
• Un workflow de GitHub Actions que bloquea merges si falla la validación.

No es sexy. Es aburrido. Pero es lo que evita que pases la noche arreglando producción porque un created_at vino null.
Esto no acaba aquí.

FAQ

• ¿Por qué no son suficientes los tipos de TypeScript?
• ¿Qué es Zod y por qué usarlo?
• ¿Dónde debo validar: en backend o frontend?
• ¿No hará lenta la app la validación runtime?
• ¿Cómo manejar campos opcionales o faltantes?
• ¿Qué patrones debo evitar hoy mismo?

Porque TypeScript opera en tiempo de compilación. Los datos de la red llegan en tiempo de ejecución y pueden diferir del contrato. Validar runtime evita errores silenciosos y fallos en producción.

Zod es una biblioteca de esquemas para validación y parsing en runtime. Proporciona validación declarativa, errores con contexto y permite inferir tipos TypeScript desde el esquema.

Valida en ambos. El backend debe proteger su dominio; el frontend debe validar boundaries externos y usuarios malformados. Si controlas ambos, puedes relajar validaciones internas, pero nunca las boundaries públicas.

Añade CPU, sí, pero para la mayoría de aplicaciones el coste es insignificante frente a la latencia de red. Para sistemas de alto rendimiento, valida selectivamente o en capas.

Decide una política: default, error o fallback. Documenta la decisión y aplica la política consistentemente en la capa de red. No improvises en handlers dispersos.

Evita usar as T indiscriminadamente, confiar en que el backend no cambiará y manejar errores con any. También evita no versionar contratos y no tener tests contra endpoints reales.

Tiempo estimado de lectura: 6 min

¿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 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:

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:

¿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();
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

Checklist práctico para cada repo

Riesgos reales y cuándo NO actualizar aún

No es un dogma: hay casos donde deberías esperar.

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:

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)

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)

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.