⏱️ Lectura: 11 min
Microsoft reescribió el compilador de TypeScript en Go y promete compilaciones hasta 10 veces más rápidas: el proyecto lo lidera Anders Hejlsberg, el arquitecto original del lenguaje, y ya circula una versión de prueba pública bajo el nombre tsgo.
📑 En este artículo
El cambio no toca la sintaxis que ya conocés: seguís escribiendo TypeScript exactamente igual. Lo que cambia es el motor que procesa ese código, y esa diferencia se nota en cada tsc --noEmit que corras en tu integración continua.
TL;DR
- Microsoft reescribió el compilador de TypeScript en Go, apodado tsgo, apuntando a compilar hasta 10 veces más rápido que la versión actual en JavaScript.
- El anuncio lo lidera Anders Hejlsberg, arquitecto original de TypeScript, desde el blog oficial del equipo en Microsoft.
- El motor nuevo se distribuye como paquete de prueba @typescript/native-preview, instalable con npm junto al compilador clásico.
- TypeScript 7 adoptará el compilador nativo en Go como motor principal, mientras la línea 6.x sigue viva en JavaScript.
- tsgo replica el mismo pipeline interno de tsc (parser, binder, checker, emisor) pero corre con concurrencia real vía goroutines.
- El proyecto es público en GitHub bajo microsoft/typescript-go y acepta pruebas de la comunidad antes del lanzamiento estable.
- No cambia la sintaxis ni las reglas de tipos de TypeScript: cambia el motor que compila, no el lenguaje que escribís.
Introducción
El compilador de TypeScript en Go es la respuesta de Microsoft a un problema que cualquier equipo con un monorepo grande conoce de memoria: el chequeo de tipos se vuelve lento a medida que el proyecto crece, y ese tiempo se paga en cada commit, en cada pull request y en cada apertura del editor.
Durante más de una década, el compilador de TypeScript (conocido como tsc) estuvo escrito en el propio TypeScript, ejecutándose sobre Node.js. Ese diseño autoalojado facilitó el desarrollo del lenguaje, pero también heredó las limitaciones de un entorno de un solo hilo. Microsoft usa su propio código base, incluido el de VS Code, como banco de pruebas interno para medir estas mejoras antes de publicarlas.
Qué pasó
El equipo de TypeScript en Microsoft confirmó que portó el pipeline completo del compilador (parser, binder, checker y emisor de JavaScript) a Go, manteniendo la misma estructura interna que ya usaba en TypeScript para minimizar diferencias de comportamiento frente al compilador actual. El resultado se distribuye como un paquete separado, @typescript/native-preview, con un binario llamado tsgo que se instala junto al compilador clásico sin tocar la configuración existente.
La promesa central del anuncio es compilar hasta 10 veces más rápido que la versión en JavaScript, aprovechando que Go compila a binario nativo y soporta concurrencia real a través de goroutines, algo que el motor de JavaScript de Node.js no ofrece de forma nativa para este tipo de carga de trabajo.
Contexto e historia
TypeScript nació en 2012 como un superset de JavaScript con tipos estáticos opcionales, y desde sus primeras versiones el propio compilador se escribió en TypeScript: un caso clásico de autoalojamiento (self-hosting) que sirvió como prueba de que el lenguaje era lo bastante maduro para construirse a sí mismo. Con los años, TypeScript se volvió el superset tipado dominante del ecosistema JavaScript, adoptado en proyectos de escala grande dentro y fuera de Microsoft.
Ese enfoque funcionó bien durante años, pero a medida que los proyectos crecieron (monorepos con cientos de miles de líneas y miles de archivos .ts) el chequeo de tipos empezó a dominar el tiempo de build. El equipo respondió con optimizaciones incrementales: project references, builds incremental, isolatedModules y mejoras puntuales al checker en cada versión. Todas ayudaron, pero ninguna atacaba la raíz del problema: un solo hilo de JavaScript procesando un árbol de tipos cada vez más grande.
La decisión de portar el compilador a Go, en lugar de reescribirlo en Rust u otro lenguaje de moda para herramientas de build, respondió a un criterio pragmático: Go tiene un recolector de basura con una filosofía cercana a la de JavaScript (lo que simplificó portar estructuras de datos y punteros circulares del checker), y su modelo de concurrencia con goroutines encaja naturalmente con el paralelismo por archivo que necesita el type-checking.
Detalles técnicos y rendimiento
La arquitectura interna de tsgo replica, etapa por etapa, la del compilador original: un parser que produce el árbol de sintaxis, un binder que resuelve símbolos y scopes, un checker que infiere y valida tipos, y un emisor que genera el JavaScript final. La diferencia está en que cada etapa corre ahora sobre un runtime con concurrencia real, lo que permite chequear archivos independientes en paralelo en lugar de en serie, algo que el modelo de un solo hilo de Node.js no permitía sin procesos separados y costosos de coordinar.
flowchart TD
A["Codigo fuente .ts"] --> B["Parser"]
B --> C["Binder"]
C --> D["Checker (tipos)"]
D --> E["Emisor JS"]
subgraph "Motor tsgo en Go"
B
C
D
endEl diagrama muestra las mismas cuatro etapas que ya existían en tsc; lo que cambia es el runtime que las ejecuta, no el diseño del compilador. Esa decisión de mantener la arquitectura intacta es la que le permite al equipo apuntar a compatibilidad casi total con el comportamiento actual del checker.
| Opción | Cuándo usarla | Ventaja | Limitación |
|---|---|---|---|
tsc (JavaScript, Node.js) |
Proyectos en producción hoy que dependen de plugins de Language Service o transformadores custom | Compatibilidad total y ecosistema maduro de herramientas | Compilación y chequeo de tipos más lentos en proyectos grandes |
tsgo (Go nativo, preview) |
Medir el tiempo de chequeo de tipos en CI o en scripts de build sin depender del editor | Arranque y compilación sensiblemente más rápidos | Todavía en preview: cobertura incompleta de plugins y del Language Service para editores |
Para confirmar qué motor estás corriendo, basta con comparar la salida de ambos binarios:
npx tsc --version
npx tsgo --versionSi ambos comandos responden con un número de versión sin errores, tenés los dos motores instalados y podés alternar entre ellos apuntando al mismo tsconfig.json.
Cómo probar el compilador de TypeScript en Go hoy
Probar el compilador de TypeScript en Go no requiere migrar nada: se instala como una dependencia de desarrollo adicional y convive con tu tsc habitual.
npm install --save-dev @typescript/native-preview
echo "const mensaje: string = 'hola mundo'; console.log(mensaje);" > hola.ts
npx tsgo hola.ts
node hola.jsEste bloque instala el paquete de prueba, escribe un archivo TypeScript mínimo y lo compila con tsgo en lugar de tsc: el resultado es el mismo JavaScript que obtendrías con el compilador clásico.
Para un proyecto real, la configuración mínima no cambia respecto a la que ya usás:
{
"compilerOptions": {
"strict": true,
"target": "ES2022",
"module": "NodeNext"
}
}tsgo lee el mismo tsconfig.json que tsc, así que no hace falta duplicar configuración para probarlo.
💡 Tip: instalá tsgo en un proyecto de prueba primero y corré tu suite de tests contra el JavaScript que emite, antes de tocarlo en el pipeline de CI real.
Para medir la diferencia en tu propio código, comparar el tiempo real de ejecución es más confiable que cualquier cifra genérica:
time npx tsc --noEmit
time npx tsgo --noEmitEl valor que importa es el campo real que reporta cada comando: depende del tamaño y la forma de tu propio código base, así que es la única cifra de rendimiento que vale para tu caso concreto.
Impacto y análisis
El impacto más inmediato de un compilador de TypeScript en Go hasta 10 veces más rápido se siente en dos lugares muy concretos: la integración continua y el editor. Un chequeo de tipos que hoy tarda varios minutos en un monorepo grande es, en la práctica, tiempo muerto entre que abrís un pull request y obtenés luz verde para mergearlo. Herramientas como esbuild o swc ya resolvieron la transpilación rápida hace tiempo, pero siguen delegando el chequeo de tipos a tsc; es justamente ese paso el que tsgo apunta a acelerar.
En el editor, el Language Service es el que le da a VS Code y a otros editores el autocompletado, el chequeo de errores en tiempo real y el «ir a la definición». Hoy ese servicio corre sobre el mismo motor JavaScript que tsc, así que la promesa de un motor nativo en Go apunta también a proyectos grandes que hoy tardan varios segundos en refrescar el árbol de tipos cada vez que guardás un archivo.
⚠️ Ojo: tsgo todavía no cubre el mismo API de plugins del Language Service que usan algunas extensiones de VS Code y algunos linters con reglas basadas en tipos; migrar tu editor o tu CI a tsgo hoy puede romper esas integraciones hasta que alcancen paridad.
Ese es el trade-off honesto del proyecto en su etapa actual: ganás velocidad de compilación y de chequeo de tipos puro, pero perdés, por ahora, parte del ecosistema de herramientas construido alrededor del compilador en JavaScript durante más de una década. Para un pipeline de CI que solo corre tsc --noEmit como gate de tipos, el cambio es prácticamente directo. Para un editor con extensiones que dependen de APIs internas del Language Service, todavía no.
Qué sigue
El objetivo declarado del equipo es que el motor nativo en Go se convierta en el compilador principal detrás de TypeScript 7, mientras la línea 6.x sigue disponible en JavaScript para quien dependa de plugins o integraciones que todavía no migraron. La prioridad pública es primero la paridad completa en type-checking y emitido de JavaScript, y después la paridad del Language Service para que los editores puedan adoptarlo sin perder funcionalidad.
La comunidad puede seguir el progreso y reportar incompatibilidades directamente en el repositorio de GitHub, donde el equipo publica issues específicos para cada brecha de compatibilidad detectada contra el compilador en JavaScript.
📖 Resumen en Telegram: Ver resumen
Probalo vos: corré npm install --save-dev @typescript/native-preview en tu proyecto y compará el tiempo de tsgo --noEmit contra tu tsc --noEmit de siempre.
Preguntas frecuentes
¿Qué es tsgo?
Es el nombre del binario del compilador de TypeScript reescrito en Go, distribuido como paquete de prueba @typescript/native-preview.
¿TypeScript 7 reemplaza a TypeScript 6?
TypeScript 7 adopta el motor nativo en Go como compilador principal; la línea 6.x en JavaScript sigue disponible durante la transición para proyectos que dependan de plugins que todavía no migraron.
¿Por qué Go y no Rust u otro lenguaje?
El equipo priorizó un recolector de basura con una filosofía cercana a la de JavaScript, lo que simplificó portar estructuras del checker, junto con un modelo de concurrencia (goroutines) que encaja con el paralelismo por archivo del type-checking.
¿Puedo usar tsgo en producción hoy?
Podés probarlo como gate de tipos en CI hoy mismo. Para el editor, conviene esperar a que el Language Service alcance paridad completa con las extensiones que ya usás.
¿Cambia la sintaxis de TypeScript?
No. El lenguaje y sus reglas de tipos son los mismos; lo que cambia es el motor que compila y chequea ese código.
¿Qué pasa con los plugins del compilador actual?
Los plugins que dependen de APIs internas del Language Service en JavaScript todavía no tienen equivalente completo en tsgo; el equipo lista esas brechas en el repositorio de GitHub del proyecto.
Referencias
- Blog oficial de TypeScript en Microsoft: anuncios y detalles técnicos del equipo del lenguaje.
- microsoft/typescript-go en GitHub: código fuente del compilador nativo en Go y seguimiento de issues de compatibilidad.
- Sitio oficial de TypeScript: documentación del lenguaje y guías de referencia.
- @typescript/native-preview en npm: paquete de instalación de la versión de prueba del compilador nativo.
📱 ¿Te gusta este contenido? Únete a nuestro canal de Telegram @programacion donde publicamos a diario lo más relevante de tecnología, IA y desarrollo. Resúmenes rápidos, contenido fresco todos los días.
Imagen destacada: Foto de Florian Olivo en Unsplash
0 Comentarios