¿Conviene actualizar ya a TypeScript 7?

Actualiza a TypeScript 7 ya si tu proyecto es TypeScript puro y compila sin errores en 6.0. Si dependes de typescript-eslint, Vue, Svelte, Astro, MDX o de la verificación de plantillas de Angular, ejecuta el tsc de 7.0 junto con 6.0 y espera a 7.1 antes de hacer el cambio completo.

Las cifras de velocidad son tentadoras. Pero entonces recuerdas que tu pipeline de linting, tus archivos .vue y un script de generación de código personalizado importan typescript, y un salto de versión mayor empieza a parecer arriesgado.

TypeScript 7.0 se publicó el 8 de julio de 2026. Este artículo explica en qué consiste la mejora de velocidad, qué cambios de configuración romperán tu build, qué herramientas aún no pueden usar 7.0 y cómo ejecutar ambos compiladores en un mismo repositorio. Termina con una recomendación para cada tipo de proyecto.

¿Cuánto más rápido es TypeScript 7?

TypeScript 7.0 es una portabilidad del compilador de TypeScript a Go, y Microsoft afirma que normalmente hace que los builds completos sean entre 8x y 12x más rápidos que con TypeScript 6.0. El equipo no rediseñó el compilador. La versión en Go replica la organización y el funcionamiento del código original, de modo que ambos compiladores producen los mismos resultados. La mejora proviene de ejecutarse como código nativo y de realizar la comprobación de tipos en varios hilos que comparten memoria.

Estas son las cifras de builds completos del anuncio de TypeScript 7.0 de Microsoft:

Microsoft ejecutó estos builds con el valor predeterminado de cuatro workers de comprobación de tipos (--checkers 4) sobre grandes bases de código open source. El anuncio no indica qué hardware se utilizó. El resultado más bajo, tldraw con 7,7x, queda ligeramente por debajo del rango de “8x a 12x” que declara Microsoft.

El tiempo que realmente ahorra TypeScript 7 depende del tamaño de tu base de código. Según las cifras de Microsoft, vscode ahorra unos 115 segundos por build completo y tldraw menos de 10. Una aplicación pequeña que ya completa la comprobación de tipos en dos segundos se acelerará en una proporción similar, pero ahorrará muy poco tiempo.

Tres cambios menores, en una línea cada uno:

• --checkers y --builders controlan la comprobación de tipos en paralelo y los builds de referencias de proyecto. Las notas de la versión 7.0 califican ambos flags como experimentales.
• --watch ahora se ejecuta sobre una portabilidad a Go del file watcher de Parcel.
• La comprobación de JS y JSDoc se ha rehecho para comportarse de forma más parecida al análisis de archivos .ts. Los detalles están en el CHANGES.md de typescript-go.

Qué se rompe al actualizar desde TypeScript 5.x o 6.0

El código que no presenta errores en TypeScript 6.0, con stableTypeOrdering activado y sin ignoreDeprecations, debería producir la misma salida en TypeScript 7.0. Todo lo que se rompe proviene de 6.0: 7.0 hereda los nuevos valores predeterminados de 6.0, y todo lo que 6.0 marcó como obsoleto ahora detiene el build. Los equipos que vienen directamente de 5.x asumen ambos conjuntos de cambios a la vez.

Nuevos valores predeterminados

Cuatro valores predeterminados de TypeScript 7.0, heredados de 6.0, causan la mayor parte de las roturas:

• strict es true. Espera nuevos errores en código con tipado poco estricto. Los helpers bien tipados construidos con tipos utilitarios de TypeScript facilitan la transición.
• module tiene como valor predeterminado esnext.
• rootDir tiene como valor predeterminado ./. Si tu tsconfig.json está por encima de src, define rootDir explícitamente.
• types tiene como valor predeterminado []. Enumera por nombre los paquetes de tipos globales como node o jest, o establece ["*"] para recuperar el comportamiento anterior.

Otros cuatro valores predeterminados cambiaron: target ahora sigue la edición de ECMAScript más reciente ya finalizada (un paso por detrás de esnext), noUncheckedSideEffectImports es true, libReplacement es false, y stableTypeOrdering es true y no se puede desactivar.

Opciones obsoletas que ahora son errores bloqueantes

Las notas de la versión TypeScript 7.0 enumeran doce opciones y comportamientos obsoletos que ahora producen errores bloqueantes:

• target: es5
• downlevelIteration
• moduleResolution: node / node10 (usa nodenext o bundler)
• moduleResolution: classic (usa bundler o nodenext)
• module: amd, umd, systemjs, none (usa esnext o preserve)
• baseUrl (escribe paths relativos a la raíz del proyecto)
• esModuleInterop o allowSyntheticDefaultImports establecidos en false
• alwaysStrict establecido en false
• La palabra clave module en declaraciones de namespace
• asserts en imports (usa with)
• /// <reference no-default-lib /> con skipDefaultLibCheck
• Rutas de archivo pasadas por línea de comandos cuando el directorio tiene un tsconfig.json, salvo que añadas --ignoreConfig

outFile no figura en esa lista, pero también ha desaparecido. Las notas de la versión 6.0 indican que 6.0 ya la eliminó, y que todas las opciones que 6.0 marcó como obsoletas se eliminan por completo en 7.0. Si todavía usas outFile, traslada esa tarea a un bundler.

También hay un cambio a nivel de tipos: la inferencia a partir de template literal types ya no divide un carácter como un emoji en dos mitades. Solo lo notarás si escribiste helpers de cadenas a nivel de tipos que dependían de la antigua división en UTF-16.

Este es un ejemplo de configuración heredada típica y la versión que funciona en 7.0:

// Before: hard errors on 7.0
{
  "compilerOptions": {
    "target": "es5",               // error: es5 unsupported
    "downlevelIteration": true,    // error: removed
    "moduleResolution": "node",    // error: node/node10 unsupported
    "baseUrl": "./src",            // error: baseUrl unsupported
    "paths": { "@/*": ["*"] }
  },
  "include": ["./src"]
}

// After: valid on 7.0
{
  "compilerOptions": {
    "moduleResolution": "bundler",
    "rootDir": "./src",
    "types": ["node", "jest"],
    "paths": { "@/*": ["./src/*"] }
  },
  "include": ["./src"]
}

La nueva versión elimina target para que se aplique el valor predeterminado, hace que paths apunte a la raíz del proyecto y define rootDir y types explícitamente.

Microsoft recomienda pasar primero a 6.0. Actualiza a 6.0, corrige todas las advertencias de obsolescencia (el anuncio de TypeScript 6.0 explica cada una), elimina ignoreDeprecations y solo entonces instala 7.0.

¿Qué herramientas aún no funcionan con TypeScript 7?

Las herramientas que importan el compilador de TypeScript como biblioteca, y las que están detrás de la verificación de plantillas de Vue, MDX, Astro, Svelte y Angular, todavía no funcionan con TypeScript 7.0, porque TypeScript 7.0 no incluye una API programática. Según el anuncio de 7.0 de Microsoft, las herramientas que importan el compilador como biblioteca, como typescript-eslint, deben seguir ejecutándose sobre TypeScript 6.0 mediante el paquete de compatibilidad @typescript/typescript6. Si tu configuración de linting con información de tipos mediante typescript-eslint depende de una peer dependency de typescript, necesitará la configuración con alias que se describe en la siguiente sección.

Los lenguajes embebidos también se ven afectados. El anuncio de 7.0 de Microsoft indica que los proyectos de Vue, MDX, Astro y Svelte deberían quedarse en TypeScript 6.0 por ahora. Volar y herramientas similares integran el soporte de TypeScript en esos formatos de archivo llamando directamente al compilador, y 7.0 no ofrece ninguna API a la que puedan llamar. La verificación de tipos en plantillas de Angular tiene la misma limitación. Para Angular, el anuncio sugiere una división: usar el tsc de 7.0 desde la línea de comandos y en CI para detectar rápidamente errores en todo el proyecto, y dejar que 6.0 se encargue del editor para que la verificación de plantillas siga funcionando.

En VS Code, la extensión específica de TypeScript 7 de Microsoft ofrece dos comandos en la paleta de comandos, “Disable TypeScript 7 Language Server” y “Enable TypeScript 7 Language Server”, para que puedas alternar el editor entre 6.0 y 7.0 siempre que lo necesites. Si el editor empieza a comportarse de forma extraña tras el cambio, el flujo habitual de depuración de TypeScript en VS Code sigue siendo válido.

Microsoft planea reincorporar una API en TypeScript 7.1, aunque no será idéntica a la anterior. Esa versión es el momento realista para que estas integraciones migren.

Cómo ejecutar TypeScript 7 y 6.0 en paralelo

Para ejecutar ambas versiones en un mismo repositorio, usa alias de npm. Haz que el nombre de paquete typescript apunte al paquete de compatibilidad de 6.0 e instala 7.0 con otro nombre. Así, las herramientas que importan typescript cargarán 6.0. El paquete de compatibilidad proporciona la API de 6.0 y además un comando de 6.0 llamado tsc6.

En un proyecto npm estándar, npx tsc ejecuta entonces 7.0. Pero hay un inconveniente. El paquete de compatibilidad depende de una copia completa de TypeScript 6.0 que declara su propio tsc, por lo que dos paquetes compiten por ese nombre de comando. Algunos usuarios han informado de que Yarn y Bun pueden enlazar tsc a 6.0 en su lugar. El script typecheck que aparece a continuación invoca directamente el archivo de 7.0, por lo que no depende de qué paquete se quede con el nombre tsc. Esta es la configuración que describe Microsoft, mostrada aquí con scripts:

{
  "devDependencies": {
    "@typescript/native": "npm:typescript@^7.0.2",
    "typescript": "npm:@typescript/typescript6@^6.0.2"
  },
  "scripts": {
    "typecheck": "node node_modules/@typescript/native/bin/tsc --noEmit",
    "typecheck:6": "tsc6 --noEmit",
    "lint": "eslint ."
  }
}

typecheck ejecuta 7.0. typecheck:6 ejecuta 6.0, lo que resulta útil para comprobar que ambos compiladores coinciden durante la migración. lint resuelve typescript a 6.0 a través del alias. Si prefieres configurar el alias de 6.0 desde la terminal, ejecuta npm install -D typescript@npm:@typescript/typescript6. Si solo haces eso, obtendrás tsc6 y nada más, así que añade también el alias de 7.0.

Ejecuta npx tsc --version para ver qué compilador invoca un tsc sin más. Microsoft solo documenta esta configuración para npm, así que verifica el resultado por tu cuenta si usas pnpm, Yarn o Bun.

¿Conviene actualizar? Recomendación según la situación

Actualizar o no a TypeScript 7 depende de dos factores: lo limpio que esté tu build en 6.0 y si alguna herramienta de tu toolchain importa el compilador.

Proyecto nuevo: empieza con 7.0. Si estás migrando de Flow a TypeScript, apunta a los valores predeterminados de 7.0 desde el principio para no tener que migrar una segunda vez.

Base de código pequeña en TS puro: pasa a 6.0, corrige todas las opciones obsoletas y luego cambia. El tiempo ahorrado será pequeño, pero estarás en la línea con mantenimiento.

Monorepo grande: configura el alias, traslada ya la comprobación de tipos en CI al tsc de 7.0 y mantén el linting, la generación de código y el editor en 6.0 hasta que 7.1 publique su API.

Conclusión

TypeScript 7.0 comprueba los tipos de tu código prácticamente igual que 6.0, solo que más rápido. Casi todo lo que se rompe proviene de las opciones obsoletas de 6.0 o de herramientas que necesitan una API del compilador. Empieza por conseguir un build limpio en 6.0 sin ignoreDeprecations. Después, cambia por completo o añade el alias de npm y deja que CI ejecute el tsc de 7.0 mientras tus herramientas siguen en 6.0 hasta la llegada de 7.1.

Preguntas frecuentes

¿tsgo o @typescript/native-preview son lo mismo que TypeScript 7?

Ya no. Antes del lanzamiento de 7.0, el compilador en Go se ofrecía como vista previa en el paquete @typescript/native-preview, y su comando era tsgo. La última versión de ese paquete es 7.0.0-dev.20260707.2, publicada el día anterior a la versión estable. En TypeScript 7.0, el compilador nativo forma parte del paquete typescript habitual y se ejecuta como tsc. Las builds nightly ahora provienen de typescript@next, así que cambia tsgo por tsc en tus scripts de CI.

¿TypeScript 7 acelera los builds con Vite, esbuild o SWC?

No. Vite, esbuild y SWC convierten TypeScript en JavaScript eliminando los tipos sin comprobarlos, por lo que nunca invocan tsc y sus tiempos de transpilación no cambian. TypeScript 7 acelera el paso independiente de comprobación de tipos, normalmente tsc --noEmit en CI o en un hook de pre-commit, y el language server del editor. Si la comprobación de tipos no es el paso más lento de tu pipeline, actualizar no acortará los builds de forma apreciable.

¿ts-node funciona con TypeScript 7?

No directamente. ts-node compila los archivos a través de la API del compilador de TypeScript, y 7.0 no incluye esa API. Con la configuración de alias de npm, el import de typescript que hace ts-node se resuelve al paquete de compatibilidad de 6.0, por lo que sigue ejecutándose sobre 6.0 mientras tsc ejecuta 7.0. Para código que solo usa sintaxis eliminable, el type stripping de las versiones recientes de Node.js puede ejecutar archivos .ts sin ningún compilador, pero no realiza comprobación de tipos.

¿TypeScript 7 todavía puede compilar a ES5 para navegadores antiguos?

No. TypeScript 6.0 elevó el target mínimo admitido a ES2015 y marcó target es5 como obsoleto. En 7.0, target es5 es un error bloqueante. Si todavía necesitas salida en ES5, haz que tsc emita ES2015 o posterior y posprocesa el resultado con Babel u otro compilador. Como alternativa, compila el código fuente de TypeScript directamente con esa herramienta externa.