TypeScript 7: el compilador nativo en Go y qué cambia en tu día a día

TypeScript 7 llegó a General Availability el 8 de julio de 2026, tras un Release Candidate publicado el 18 de junio. Y lo hizo con un titular que se ha repetido hasta la saciedad: compilaciones hasta 12 veces más rápidas.

Pero detrás del titular hay algo que conviene entender bien, porque la mayoría de las explicaciones que circulan mezclan dos cosas distintas. TypeScript 7 no es un lenguaje nuevo ni un rediseño. Es el mismo TypeScript, con el mismo sistema de tipos, ejecutado sobre un motor completamente distinto.

Qué es TypeScript 7 (y qué no es)

Vayamos con lo importante, porque de esto depende que tu migración sea trivial o un infierno.

TypeScript 7 es un port nativo a Go del compilador. No es una reescritura de la lógica de tipos. Microsoft lo ha dicho explícitamente: el type-checking es estructuralmente idéntico a TypeScript 6. El compilador hace lo mismo, pero en lugar de ejecutarse sobre JavaScript lo hace sobre código Go compilado, con acceso a paralelización multihilo real.

Eso implica tres consecuencias directas:

• El lenguaje no cambia. Mismos tipos, misma semántica, mismas reglas. Tu código no se comporta distinto porque el motor sea otro.
• La ganancia es de velocidad, no de funcionalidad. No esperes nuevas capacidades de tipado por actualizar.
• Los cambios que sí vas a notar vienen de TypeScript 6, que actuó como puente: introdujo las deprecaciones que TypeScript 7 convierte en errores duros.

Y un matiz técnico que mucha gente pasa por alto: TypeScript 7.0 no incluye API programática. Llega en la 7.1. Esto afecta a herramientas que consumen el compilador como librería, como typescript-eslint. Para esos casos existe un paquete de compatibilidad que veremos más adelante.

Los números: benchmarks reales

Aquí es donde el port a Go deja de ser teoría. Estas son las cifras de builds completos comparando TypeScript 6 con TypeScript 7, usando los --checkers 4 que van por defecto:

Si subimos a --checkers 8, la cosa mejora todavía más:

No es solo velocidad, también es memoria. El consumo agregado del build baja de forma notable:

La experiencia en el editor

Los builds son importantes, pero donde de verdad se nota el cambio es en el día a día del editor. En el código de VS Code, el tiempo hasta el primer error pasó de 17,5 s a menos de 1,3 s, más de 13 veces más rápido.

El language server también mejora en fiabilidad: más de un 80 % menos de comandos fallidos y más de un 60 % menos de crashes que con TypeScript 6. Quien haya trabajado en un monorepo grande sabe exactamente lo que significa eso.

Casos reales citados por Microsoft

Más allá de los benchmarks sintéticos, hay empresas que ya lo están usando en producción:

• Slack: 40 % menos tiempo en la merge queue y su CI de type-check bajó de 7,5 minutos a 1,25 minutos.
• Canva: el tiempo hasta el primer error pasó de 58 s a 4,8 s.
• News Services (Microsoft): 400 horas al mes ahorradas en CI.
• Vanta: hasta 9× de mejora.

Nuevos valores por defecto

Estos valores por defecto se adoptaron ya en TypeScript 6 y TypeScript 7 los consolida. Son la causa de la mayoría de «¿por qué no compila igual que antes?»:

• strict: true por defecto.
• module pasa a esnext.
• target pasa a la versión estable de ECMAScript inmediatamente anterior a esnext.
• noUncheckedSideEffectImports: true.
• libReplacement: false.
• stableTypeOrdering: true, y este no se puede desactivar.
• rootDir pasa a ./, lo que obliga a declarar los directorios fuente internos.
• types pasa a []. Si quieres el comportamiento antiguo, tienes que poner ["*"] explícitamente.

Los dos últimos son los que más sorpresas generan en proyectos reales, sobre todo en monorepos con una estructura de carpetas no estándar.

Las 12 deprecaciones que ahora son error

En TypeScript 6 estas opciones avisaban. En TypeScript 7 fallan, y además su comportamiento es no-op: aunque las escribas, no hacen nada. Estas son las doce:

1. target: es5.
2. downlevelIteration.
3. moduleResolution: node o node10.
4. module: amd, umd, systemjs o none.
5. baseUrl.
6. moduleResolution: classic.
7. esModuleInterop o allowSyntheticDefaultImports puestos a false.
8. alwaysStrict puesto a false.
9. La palabra clave module en namespaces.
10. asserts en imports (hay que usar with).
11. /// <reference no-default-lib />.
12. CLI con rutas de fichero cuando existe un tsconfig.json, salvo que uses --ignoreConfig.

Si tu tsconfig.json lleva años arrastrándose entre proyectos, es muy probable que tenga dos o tres de estas.

Paralelización: --checkers y --builders

La paralelización es la razón de fondo por la que Go da estas cifras. Estos son los flags que la controlan:

npm install -D typescript          # TypeScript 7 GA
npx tsc --checkers 8               # más workers de type-check (más RAM)
npx tsc --builders 4               # builds paralelos de project references
npx tsc --singleThreaded           # depurar / CI con pocos recursos

El detalle importante: --checkers y --builders se multiplican. Un --checkers 4 con --builders 4 puede llegar a levantar hasta 16 type-checkers simultáneos. En una máquina potente eso es maravilloso; en un runner de CI con pocos núcleos, puede empeorar el tiempo total por contención. En runners pequeños, --checkers 1 suele ser la opción sensata.

Migración de tsconfig: antes y después

Este es el cambio concreto que vas a tener que hacer en la mayoría de proyectos. Así se ve un tsconfig.json heredado de TypeScript 5.x:

// ANTES (TS 5.x)
{
  "compilerOptions": {
    "target": "es5",
    "module": "commonjs",
    "moduleResolution": "node",
    "baseUrl": "./src",
    "strict": false
  },
  "include": ["./src"]
}

Y así queda migrado a TypeScript 7:

// DESPUÉS (TS 7)
{
  "compilerOptions": {
    "target": "es2022",
    "module": "esnext",
    "moduleResolution": "bundler",   // o "nodenext" para Node puro
    "strict": true,
    "rootDir": "./src",
    "types": ["node"]
  },
  "include": ["./src"]
}

Fíjate en los cuatro cambios que importan: target sale de ES5, moduleResolution deja node, baseUrl desaparece (los paths pasan a ser relativos a la raíz del proyecto) y strict se activa. Ese último puede destapar errores que llevaban años escondidos. Es incómodo, pero es exactamente el objetivo.

Convivencia con TypeScript 6: @typescript/typescript6

Como TypeScript 7.0 no trae API programática, hay herramientas que todavía necesitan el compilador «clásico». Para eso se publica @typescript/typescript6, que te permite tener las dos versiones instaladas a la vez:

npm install -D typescript@npm:@typescript/typescript6

// package.json — tsc6 para tooling con API, tsc de TS 7 para builds
{
  "devDependencies": {
    "@typescript/native": "npm:typescript@^7.0.2",
    "typescript": "npm:@typescript/typescript6@^6.0.2"
  }
}

Además, si quieres probar lo que viene antes de que llegue, existe la nightly: npm install -D typescript@next. Esta sustituye al antiguo @typescript/native-preview, que llegó a acumular más de 8,5 millones de descargas semanales.

Detectar diferencias 6 a 7 antes de migrar

Si quieres saber qué va a cambiar en tu proyecto antes de dar el salto, puedes usar --stableTypeOrdering, que solo existe en TypeScript 6:

npx -p typescript@6 tsc --stableTypeOrdering

Este flag añade hasta un 25 % de ralentización, así que no es para producción: es una herramienta de diagnóstico para comparar el orden de tipos entre 6 y 7 y detectar diferencias antes de que te sorprendan.

Errores comunes

Estos son los tropiezos que más se repiten al migrar:

• rootDir y types son los cambios «sorprendentes». Si tu tsconfig.json está fuera de src/, tendrás que declarar rootDir a mano.
• baseUrl eliminado. Migra los paths a rutas relativas a la raíz del proyecto.
• --stableTypeOrdering no es para producción. Hasta un 25 % de ralentización. Solo para diagnóstico.
• --checkers y --builders multiplican. En CI con pocos núcleos, usa valores bajos o --singleThreaded.
• Variar --checkers puede alterar resultados dependientes del orden en casos raros. Fija el mismo número entre entornos para evitar diferencias fantasma.
• Sin API en la 7.0. Si tu tooling la necesita, instala @typescript/typescript6.

Conclusión

TypeScript 7 es, probablemente, la actualización más limpia que vas a hacer este año. No cambia el lenguaje, no cambia tu código, no cambia la semántica de tipos. Cambia el motor, y con él la velocidad: builds de 11,9× en proyectos como VS Code, memoria hasta un 26 % menor y una experiencia de editor que pasa de 17,5 segundos a menos de 1,3 segundos hasta el primer error.

El trabajo real de la migración no está en TypeScript 7, está en el tsconfig.json que llevas arrastrando desde TypeScript 5.x. Las doce deprecaciones que ahora son error duro son, en la práctica, una lista de deuda técnica acumulada que toca saldar. Si usas PM2 para desplegar tus aplicaciones Node, el cambio de compilador no te obliga a nada más, pero conviene revisar que el build de CI siga generando lo mismo: tienes el contexto en Despliegue de aplicaciones Node con PM2.

Mi recomendación: actualiza, arregla el tsconfig, deja --checkers en un valor sensato para tu hardware y aprovecha el margen para activar strict de verdad.

Artículos relacionados

• Cómo integrar OpenCode con GitHub Actions
• Despliegue de aplicaciones Node con PM2
• El módulo crypto de Node.js

Artículo escrito por Roberto Serrano — Desarrollador web, automatizaciones e IA en Tarragona, España.