tsgo: qué cambia en el compilador TypeScript reescrito en Go y qué significa para proyectos reales

Cometí el error de descartar tsgo como hype antes de leerlo. Vi el titular "10x más rápido" y lo puse en la misma carpeta mental que los benchmarks de frameworks JavaScript: números reales en un contexto que nada tiene que ver con lo mío. Me alcanzó con abrir el repositorio oficial y el anuncio del equipo de TypeScript para entender que esta vez la historia es distinta — y que vale la pena entender exactamente qué cambió, qué todavía no, y cuándo tiene sentido explorar la migración.

Mi tesis es simple: tsgo es una apuesta técnica legítima con evidencia pública que la respalda, pero la beta tiene limitaciones documentadas que la mayoría de los posts entusiastas omiten. El criterio para migrarlo hoy no es si el número te parece atractivo — es si tu CI tarda más de 5 minutos en type-check. Si no llegás a ese umbral, esperá la stable y dormí tranquilo.

tsgo typescript compiler go: qué es y de dónde viene

El proyecto oficial vive en github.com/microsoft/typescript-go. No es un fork ni un experimento de comunidad: es el propio equipo de TypeScript portando el compilador a Go nativo, con el objetivo declarado de aprovechar paralelismo real y eliminar el overhead de V8.

El anuncio oficial en el TypeScript Blog es claro sobre el razonamiento: JavaScript tiene un techo en cuanto a velocidad de compilación porque corre sobre un runtime de propósito general. Go permite compilar a binario nativo, gestionar goroutines para paralelismo genuino y evitar la presión del garbage collector de V8. El resultado según las mediciones del propio equipo: compilaciones que en TypeScript clásico toman decenas de segundos bajan a pocos segundos o menos.

Lo importante es que tsgo no cambia el sistema de tipos. La semántica de TypeScript — los mismos errores, las mismas inferencias, el mismo comportamiento de strict — sigue siendo idéntica. Lo que cambia es la velocidad con la que llegás a esos resultados.

# Instalación experimental según el repo oficial
# No está en npm stable todavía — seguí el README del repo
git clone https://github.com/microsoft/typescript-go
cd typescript-go

# Compilar el binario (requiere Go instalado)
go build ./cmd/tsgo

# Correr type-check sobre un proyecto
./tsgo --project ruta/a/tsconfig.json

Qué limitaciones tiene la beta hoy

Acá es donde la mayoría de los posts se quedan cortos. El roadmap del repositorio oficial documenta explícitamente qué no está listo en la beta:

Language Service (LSP) incompleto. La integración con editores — VS Code, Neovim, cualquier cliente LSP — está en progreso pero no tiene paridad con tsc. Esto significa que no podés reemplazar hoy el servidor de lenguaje que te da hover types, go-to-definition y autocompletado. El type-check de CLI es lo más maduro.

Build mode y project references. El soporte para tsc --build con composite: true y references entre paquetes de un monorepo está parcialmente implementado. Si usás pnpm workspaces con múltiples tsconfig.json enlazados, vas a encontrar casos borde.

Plugins de TypeScript. Los plugins del tsconfig.json que muchos frameworks usan internamente (Next.js incluye el suyo) no tienen soporte garantizado todavía.

Transformaciones de código. tsgo en beta es un type-checker, no un transpiler completo. No reemplaza a tsc cuando necesitás emitir .js desde .ts con transformaciones. Eso sigue siendo territorio del compilador original o de herramientas como esbuild/swc.

// tsconfig.json típico en un proyecto Next.js con strict mode
// Lo que tsgo puede type-checkear hoy (CLI)
{
  "compilerOptions": {
    "strict": true,
    "noEmit": true,         // ← modo "solo type-check, no emitir" — el caso más maduro en tsgo
    "target": "ESNext",
    "moduleResolution": "Bundler",
    "paths": {
      "@/*": ["./src/*"]
    }
  }
}
// Lo que NO está listo: plugins como el de Next.js, composite + references complejos

Si tenés strict: true activo — y si no sabés por qué deberías, tengo un post sobre las opciones del tsconfig que más impactan en producción — tsgo respeta exactamente esa semántica. El port no relaja ni cambia los checks.

Los errores comunes al evaluar tsgo

Error 1: comparar el número sin contexto de proyecto. El "10x" viene de benchmarks con codebases grandes. En un proyecto de 50 archivos donde tsc --noEmit tarda 8 segundos, el salto va a ser perceptible pero no dramático. En un monorepo con 500+ archivos donde el type-check en CI tarda 4-6 minutos, la diferencia cambia el pipeline de forma concreta.

Error 2: asumir que reemplaza toda la cadena de herramientas. tsgo en beta es un binario de type-check. No reemplaza esbuild, swc, ni el next build. La mayoría de los monorepos modernos ya separaron type-check de transpilación — si el tuyo no, este es el momento de hacerlo independientemente de tsgo.

# Separar type-check de build en CI — patrón recomendado hoy
# Paso 1: type-check (candidato para tsgo cuando sea stable)
pnpm tsc --noEmit --project tsconfig.json

# Paso 2: build/transpilación (sigue con tsc o next build, no tsgo todavía)
pnpm next build

Error 3: ignorar el Language Service. Varios posts de entusiasmo recomiendan cambiar el typescript.tsdk de VS Code apuntando a tsgo. El resultado hoy es inconsistente: algunas features funcionan, otras no. A menos que estés experimentando conscientemente, no lo hagas en un entorno donde necesitás desarrollar.

Error 4: perder de vista que los plugins importan. Next.js 15+ usa un plugin TypeScript propio para tipear correctamente los props de Server Components y los parámetros de generateMetadata. Si tsgo no lo carga, vas a perder esos checks. Eso no es un problema de tsgo — es una limitación documentada de la beta que hay que rastrear antes de adoptarlo.

Matriz de decisión: cuándo explorar tsgo hoy

No toda decisión de herramienta necesita una hoja de cálculo. Esta sí necesita criterio claro porque el costo de una migración prematura es real: romper el feedback loop del editor justo cuando más lo necesitás.

El único escenario donde veo valor inmediato es un pipeline de CI donde el type-check es el cuello de botella documentado y podés correr tsgo en un job paralelo sin afectar el build principal. Así explorás sin riesgo.

# Ejemplo de job paralelo en GitHub Actions para evaluar tsgo
# Sin tocar el build principal
jobs:
  typecheck-experimental:
    runs-on: ubuntu-latest
    continue-on-error: true  # no bloquea el pipeline si tsgo falla
    steps:
      - uses: actions/checkout@v4
      - name: Instalar Go
        uses: actions/setup-go@v5
        with:
          go-version: '1.22'
      - name: Clonar y compilar tsgo
        run: |
          git clone https://github.com/microsoft/typescript-go /tmp/tsgo
          cd /tmp/tsgo && go build ./cmd/tsgo
      - name: Medir time-check con tsgo
        run: |
          time /tmp/tsgo/tsgo --project tsconfig.json
      - name: Medir time-check con tsc (para comparar)
        run: |
          time pnpm tsc --noEmit

Este approach tiene una ventaja concreta: obtenés datos reales de tu proyecto, no del benchmark de Microsoft. Esa diferencia importa.

Qué no podés concluir sin experimento propio

Lo incómodo de este tema es que la evidencia pública respalda el claim de velocidad pero no puede decirte cuánto va a mejorar tu pipeline específico. Depende de la cantidad de archivos, la complejidad de tipos, si usás conditional types pesados, cuántos paths tiene el tsconfig, y si tenés plugins que tsgo no carga.

Lo que sí podés concluir sin experimento:

• tsgo no va a cambiar la semántica de los errores — misma especificación del sistema de tipos
• tsgo no es un reemplazo drop-in hoy — tiene limitaciones documentadas en el repo oficial
• La apuesta técnica de reescribir en Go tiene justificación sólida más allá del marketing: paralelismo nativo, binario sin V8, gestión de memoria diferente

Lo que necesitás medir vos mismo:

• Ganancia real de tiempo en tu codebase específica
• Si los plugins que usás están soportados
• Comportamiento del Language Service en tu editor

Sin esas tres mediciones, cualquier claim de "migralo ya" o "no vale nada" es ruido.

FAQ: tsgo typescript compiler go

¿tsgo reemplaza completamente a tsc hoy? No. En la beta actual, tsgo es principalmente un type-checker de CLI (--noEmit). No reemplaza la emisión de código, los plugins de TypeScript ni tiene paridad completa en el Language Service para editores. El repositorio oficial documenta el roadmap con lo que falta.

¿El sistema de tipos de tsgo es idéntico al de TypeScript original? Sí, esa es la premisa del proyecto. El port a Go replica la misma semántica de tipos — los mismos errores, las mismas inferencias, el mismo comportamiento de strict. Si encontrás una diferencia, es un bug del port, no un feature.

¿Funciona con Next.js? Parcialmente. El type-check básico funciona, pero el plugin TypeScript que Next.js incluye para tipar Server Components y metadata no está garantizado en la beta. Para proyectos Next.js en producción, esperá que el soporte de plugins esté estable.

¿Vale la pena probarlo en un monorepo con pnpm workspaces? Depende del tamaño. Si tenés project references (composite: true) entre paquetes, el soporte es parcial según la documentación oficial. Si simplemente corrés tsc --noEmit sobre el root, es el escenario más maduro para experimentar.

¿Cuándo va a estar en stable? El roadmap del repositorio oficial no tiene fecha pública. La señal para esperar es: LSP completo, soporte de plugins verificado y paridad documentada con tsc. Seguí el repo — los milestones están públicos.

¿Cambio el typescript.tsdk de VS Code a tsgo ya? No lo haría en un entorno de desarrollo activo. El Language Service de tsgo en beta tiene features incompletas que van a romper el hover types y el autocompletado en casos específicos. Si querés experimentar, hacelo en una branch dedicada con ese propósito.

Mi postura y el próximo paso concreto

tsgo es la movida técnica más interesante del ecosistema TypeScript en años. No porque el número "10x" sea mágico, sino porque el cuello de botella real del compilador siempre fue el runtime de JavaScript — y esa limitación ahora tiene una respuesta seria con evidencia pública.

Lo que no compro es el entusiasmo que ignora las limitaciones documentadas. La beta actual tiene un scope claro: type-check de CLI en proyectos sin plugins complejos. Eso no es poca cosa — para muchos pipelines de CI es exactamente el caso de uso crítico — pero tampoco es el reemplazo completo que algunos posts presentan.

Mi recomendación práctica: si el type-check es el cuello de botella documentado en tu CI, armá un job paralelo con continue-on-error: true, medí el delta en tu codebase real y tomá la decisión con datos propios. Si no tenés ese problema hoy, cerrá esta pestaña y revisalo cuando el equipo anuncie la stable. No hay urgencia.

El próximo paso para vos es uno solo: entrar al repositorio oficial y revisar los issues abiertos de las features que usás. Ahí está la información real, no en los titulares.

Fuentes originales:

• TypeScript Go — GitHub Repository: https://github.com/microsoft/typescript-go
• TypeScript Blog — Announcing TypeScript Go: https://devblogs.microsoft.com/typescript/typescript-native-port/