TypeScript 7.0 es 10 veces más rápido y está escrito en Go. Así puede adoptarlo sin romper el CI.
Microsoft publicó el Release Candidate de TypeScript 7.0 el 18 de junio de 2026, y el titular no es una nueva sintaxis. Es el compilador en sí. Durante el último año, el equipo migró TypeScript desde su propia base de código JavaScript a Go, y el resultado verifica tipos aproximadamente 10 veces más rápido que TypeScript 6.0. Los números publicados son contundentes: la base de código de VS Code, con cerca de 1,5 millones de líneas, pasa de una verificación de tipos de 77,8 segundos a 7,5 segundos. Sentry pasa de 133 segundos a 16. El inicio del editor cae de aproximadamente 9,6 segundos a 1,2, y el uso de memoria se reduce a la mitad.
Dos detalles importan más que la velocidad bruta. En primer lugar, esto es una migración, no una reescritura desde cero. El equipo trasladó la lógica de verificación de tipos existente a Go y mantuvo la semántica, por lo que la versión 7.0 debería aplicar las mismas reglas que su código ya supera en la 6.0. En segundo lugar, se instala como cualquier otra versión, directamente desde el paquete typescript en npm. Se tiene previsto un lanzamiento estable en aproximadamente un mes, y los errores de regresión van al repositorio microsoft/typescript-go en lugar del principal de TypeScript.
¿Qué gana realmente un equipo con un compilador 10 veces más rápido? Más de lo que parece a primera vista.
La ventaja no es su portátil, es el CI
Un editor más rápido está bien. Un CI más rápido cambia la forma en que trabaja la gente. Cuando desarrollamos aplicaciones nativas en la nube para clientes empresariales en PHP y Docker, la verificación de tipos suele ser una de las puertas más lentas en el pipeline, y está en la ruta crítica de cada fusión. Reducir una verificación de dos minutos a quince segundos no solo ahorra dos minutos. Cambia el comportamiento. Los desarrolladores dejan de agrupar cambios para esquivar el pipeline lento, los revisores reciben el visto bueno mientras el contexto todavía está fresco, y el hábito de «simplemente fusiono y espero al CI» que silenciosamente rompe main empieza a desaparecer.
Hemos visto a equipos diseñar su arquitectura alrededor de herramientas lentas sin darse cuenta: solicitudes de extracción gigantes, verificaciones locales omitidas, un reflejo de --no-verify en cada commit. La mayor parte de eso es una respuesta a la retroalimentación que tarda demasiado. Elimine la espera y muchos de esos hábitos pierden su razón de ser.
Un compilador más rápido sigue siendo un cambio de dependencia
Esta es la parte que se pierde en el entusiasmo. Cambiar el compilador por un binario escrito en un lenguaje diferente es una decisión de cadena de suministro, no una ganancia gratuita. Durante nuestro trabajo de pentesting y revisión de seguridad, la cadena de herramientas de construcción es uno de los primeros lugares que revisamos, porque se ejecuta con acceso completo a su código fuente y, a menudo, a sus secretos, en cada máquina de desarrollador y en cada ejecutor de CI. Un nuevo tsc es exactamente ese tipo de componente.
Nada de esto significa que el RC sea arriesgado de probar. Microsoft lo ha estado ejecutando en bases de código de varios millones de líneas dentro y fuera de la empresa durante más de un año. Significa que debería adoptarlo de forma deliberada: fije la versión exacta, lea el registro de cambios antes de actualizarlo, y no permita que un ingeniero cambie silenciosamente el compilador para todo el equipo un viernes por la tarde.
Qué hacer esta semana
No convierta la versión 7.0 en su verificación de CI bloqueante todavía. Añádala junto a la que ya tiene. La mayoría de los sistemas de CI permiten ejecutar un segundo trabajo que compila con typescript@rc e informa de su resultado sin bloquear la fusión. Ejecútelos ambos durante un par de semanas, compare los errores y sabrá exactamente dónde la 7.0 difiere de su compilación actual antes de que importe. Como es una migración en lugar de una reescritura, la mayoría de los equipos descubren que la diferencia está vacía, pero los pocos que se encuentran con un caso límite querrán descubrirlo a su propio ritmo, no durante una actualización apresurada después de que llegue la versión estable.
Este patrón no es específico de TypeScript. Usamos el mismo enfoque paralelo en nuestro trabajo web y móvil siempre que una herramienta fundamental lanza una versión principal. Preparamos una actualización de Xcode o Android Gradle Plugin en nuestros proyectos nativos de iOS y Android de la misma manera, en un trabajo paralelo, mucho antes de que llegue a la máquina de todos. Los equipos que salen perjudicados suelen ser los que leen «los tests siguen pasando» como prueba de que nada ha cambiado. Si quiere saber cómo lo hacemos en la práctica, nuestro trabajo de desarrollo está diseñado exactamente alrededor de este tipo de actualizaciones graduales y sin drama.
Si le resulta familiar un pipeline lento que su equipo ha aprendido silenciosamente a sortear, hablemos.