TypeScript 7.0 salió el 8 de julio, y no es otro release incremental — es la versión estable y de disponibilidad general del compilador nativo en Go que el equipo viene construyendo desde hace más de un año. Si estabas esperando que se le cayera la etiqueta de beta antes de probarlo en un proyecto real, este es el momento.
Qué cambió en serio
TypeScript 7 reemplaza el viejo compilador basado en JavaScript (el codebase “Strada”) por un port nativo escrito en Go. El resultado, según los propios benchmarks de Microsoft sobre un puñado de codebases open-source grandes, es un speedup de build completo de entre 8x y 12x:
| Codebase | TypeScript 6 | TypeScript 7 | Speedup |
|---|---|---|---|
| vscode | 125.7s | 10.6s | 11.9x |
| sentry | 139.8s | 15.7s | 8.9x |
| bluesky | 24.3s | 2.8s | 8.7x |
| playwright | 12.8s | 1.47s | 8.7x |
| tldraw | 11.2s | 1.46s | 7.7x |
Vale la pena aclarar: estos son números self-reported por Microsoft sobre proyectos que ellos mismos eligieron, no benchmarks independientes de terceros — pero la metodología (tiempos concretos de antes/después sobre repos nombrados y verificables) es lo bastante sólida como para tomarla en serio. Varios equipos (Slack, Vanta, Canva, PowerBI) compartieron resultados similares en el post de Microsoft, aunque esas citas también fueron curadas por Microsoft y no verificadas de forma independiente.
El uso de memoria también bajó — entre 6% y 26% menos memoria pico en el mismo set de pruebas, según el proyecto.
Instalarlo hoy
Sin paquete separado, sin flag de opt-in. TypeScript 7 se distribuye bajo el paquete typescript de siempre:
npm install -D typescript
Eso te da el nuevo binario tsc directamente — sin prefijo tsgo, sin necesidad de extension de preview para el CLI.
Qué cambia en tu editor
Si usás VS Code, instalá la extension de TypeScript 7 y se convierte en tu language server por defecto de inmediato (podés volver atrás con “Disable TypeScript 7 Language Server” desde el command palette si algo se rompe). VS Code va a integrar este soporte de forma nativa en las próximas semanas. Si usás Visual Studio, lo tenés automático según tu workspace — no hay nada que configurar.
El language server ahora corre sobre LSP en vez del viejo protocolo custom TSServer, y es multithread — por eso operaciones de editor como find-all-references y diagnostics se sienten casi instantáneas en codebases grandes, no solo en los builds completos.
Dos flags que conviene conocer
--checkers N— controla cuántos workers de type-checking corren en paralelo (default 4). Subirlo a 8 en máquinas más potentes llevó el build de vscode a 16.7x en las pruebas de Microsoft, a costa de más memoria.--singleThreaded— desactiva la paralelización por completo. Útil para debugging o para correrlo en entornos con recursos limitados, como algunos runners de CI.
Antes de migrar: qué se rompe en serio
TypeScript 7 hereda los nuevos defaults de TypeScript 6.0, y trata varios flags deprecados de 6.0 como error duro en vez de warning. Las dos cosas que más probablemente te agarren desprevenido:
rootDirahora tiene como default./— si tutsconfig.jsonvive fuera de una carpeta comosrc, vas a tener que setearrootDirexplícitamente.typesahora tiene como default[]en vez de traer todo lo que hay en@types— vas a tener que listar los paquetes que realmente usás (por ejemplo,"types": ["node", "jest"]).
Removidos por completo, sin fallback: target: es5, moduleResolution: node/classic, module: amd/umd/systemjs, y baseUrl.
Si todavía dependés de la API vieja
TypeScript 7.0 todavía no trae una API programática — eso llega con 7.1. Si tu tooling (como typescript-eslint) todavía necesita la API de 6.0, Microsoft publicó un paquete de compatibilidad, @typescript/typescript6, para que puedas correr tsc sobre 7.0 mientras otras herramientas siguen usando la API vieja vía un alias de npm. Lo mismo aplica si trabajás con Vue, Astro, Svelte o Angular — esos ecosistemas todavía dependen de la API de TypeScript 6.0 por debajo, así que no estás del todo libre para migrar si tu tooling depende de ellos.
¿Conviene migrar ya?
Para builds directos con tsc y uso en el editor, sí — tanto el CLI como el language server se describen como production-ready, y existe un camino de compatibilidad para lo que todavía necesite la API vieja. Si tu stack depende de herramientas que embeben el compilador de TypeScript directamente, vale la pena esperar a la API de 7.1 antes de ir all-in.