tsrs es un port a Rust del compilador de TypeScript 7 que ya puedes instalar desde npm, y en nuestra prueba fue entre 2,9x y 6,5x más rápido que tsc 7.0.2, con entre 2x y 4,2x menos memoria. Cloudflare, VoidZero y Max Schwenk, de Owner.com, lo anunciaron el 20 de octubre de 2026. El proyecto se incuba dentro del toolchain Oxc y se desarrolla en colaboración con el equipo de TypeScript.
yoDEV Tested · 20 de octubre de 2026 Ejecutamos tsrs 0.18.0 frente a tsc 7.0.2, tsc-rs 0.7.0 y bun check 1.4.3 sobre zod, playwright y hono, en una máquina Linux de 2 vCPU. Los resultados que reportamos como nuestros salen de esa prueba.
¿Qué es tsrs, el compilador de TypeScript en Rust?
tsrs es un reemplazo directo (drop-in replacement) del compilador de TypeScript 7 (tsc) y de su servidor de lenguaje, escrito en Rust. Lee tu tsconfig.json actual, emite JavaScript y declaraciones igual que tsc, y admite --watch, -b y un modo LSP para editores. Su objetivo declarado es 100 por ciento de conformidad con TypeScript, con menos memoria y un type checking más rápido.
No es un fork. El anuncio de Cloudflare lo deja claro: el equipo de TypeScript sigue controlando el diseño del lenguaje, y tsrs debe seguir las decisiones de upstream, no tomar las suyas. Hoy sigue la rama principal de microsoft/TypeScript, y cada versión del paquete indica el commit que porta: 0.18.0-ts7.1.0-dev.20260929 es tsrs 0.18.0 siguiendo TypeScript 7.1.0-dev.20260929.
Dos datos que conviene saber desde el principio:
- Lo escribieron agentes de IA. Max Schwenk, Head of AI Developer Experience en Owner.com, lo empezó el 30 de septiembre preguntándose si Claude Opus 5.5 podía portar el compilador a partir del código en Go de TypeScript. Según su propio relato, no escribió código él mismo: los agentes trabajaron con la suite de conformidad de TypeScript como especificación. El 19 de octubre el proyecto pasó a
oxc-project/tsrs, bajo Cloudflare y VoidZero. - Por qué lo construyó Owner.com. Su código principal tiene unos 37.000 archivos TypeScript. Con TypeScript 7.0, un chequeo con un solo hilo tardaba 80 segundos y usaba 19 GiB de memoria. Con tsrs, Owner reporta unos 7 segundos en CI.
Licencia: Apache-2.0, como derivado de TypeScript. El README aclara que no está afiliado ni respaldado por Microsoft.
¿Cómo instalar tsrs?
Agrégalo como dependencia de desarrollo y ejecútalo donde ejecutarías tsc:
pnpm add -D tsrs
pnpm exec tsrs --noEmit
Con npm, el anuncio de Cloudflare usa:
npm install tsrs
npx tsrs
Para probarlo sin agregarlo al proyecto: pnpm dlx tsrs -p .
Comandos útiles de la documentación de uso:
pnpm exec tsrs -p path/to/project # compilar
pnpm exec tsrs -p path/to/project --noEmit # solo type check
pnpm exec tsrs -p . --extendedDiagnostics # contadores y tiempos
pnpm exec tsrs --version
tsrs --watch -p . # recompila al guardar
tsrs --lsp -stdio # servidor de lenguaje para el editor
El launcher de npm instala un binario nativo para tu plataforma como dependencia opcional @tsrs/<os>-<arch>. También hay un playground en el navegador (tsrs-playground.void.app) y una build en WebAssembly, @tsrs/wasm, para Node y navegadores.
Lo que todavía no hace: --init y --showConfig no están soportados, así que mantén tsc a mano para generar la configuración.
¿tsrs es más rápido que tsc? Nuestro benchmark
Sí: en nuestra prueba fue entre 2,9x y 6,5x más rápido que tsc 7.0.2 (el compilador en Go, también conocido como tsgo). La cifra de hasta 8x más rápido con alrededor de 70 por ciento menos memoria es el benchmark propio de Cloudflare: tsrs contra TypeScript 7.0 con el mismo número de workers de chequeo. El benchmark publicado por el proyecto usó 17 proyectos en una máquina de CI de 16 vCPU y 63 GB, y el código está en el repo, en bench/.
Queríamos números en una máquina más chica, así que repetimos el montaje de nuestra prueba de bun check: los mismos tres repos, 2 vCPU, 7 GB de RAM, una ejecución de calentamiento más cinco medidas (diez en hono), mediana del tiempo total y pico de memoria.
| Proyecto | tsc 7.0.2 | tsrs 0.18.0 | tsc-rs 0.7.0 | bun check 1.4.3 |
|---|---|---|---|---|
| zod (593 errores) | 5,82 s · 1.118 MB | 0,90 s · 266 MB | 1,46 s · 632 MB | 1,42 s · 192 MB |
| playwright (5.664 errores) | 3,12 s · 581 MB | 0,73 s · 195 MB | 1,19 s · 417 MB | 1,05 s · 189 MB |
| hono, config de build (limpio, 364 archivos) | 0,32 s · 98 MB | 0,11 s · 49 MB | 0,10 s · 103 MB | — |
Frente a tsc 7.0.2, tsrs fue:
- zod: 6,5x más rápido, 4,2x menos memoria
- playwright: 4,3x más rápido, 3,0x menos memoria
- hono: 2,9x más rápido, 2,0x menos memoria
Dos cosas nos llamaron la atención. Primero, la ganancia no es solo paralelismo: con un único hilo de chequeo en ambos (--checkers 1), tsrs siguió siendo 4,8x más rápido en zod y 3,3x en playwright. Segundo, se sostiene en proyectos chicos. En nuestra prueba anterior, bun check fue más lento que tsc en el build limpio de hono; tsrs fue casi tres veces más rápido con la misma configuración.
¿tsrs o bun check?
tsrs fue más rápido que bun check en los dos repos grandes. En memoria quedaron parejos en playwright, pero en zod tsrs usó más (266 MB frente a 192 MB). Si la memoria te importa más que la velocidad, --checkers 1 bajó tsrs a 195 MB en zod y se mantuvo por debajo de 1,2 segundos.
¿Qué flags controlan la velocidad y la memoria?
tsrs agrega algunas opciones de rendimiento a los flags estándar de tsc:
--checkers Ndefine cuántos hilos de chequeo usar. Por defecto, uno por núcleo hasta 16.--singleThreadedusa un solo hilo, para el menor consumo de memoria.--maxMemory <size>(por ejemplo12G, solo con--noEmit) mantiene el proceso cerca de ese límite, cambiando CPU por memoria.--checkerCostCache <file>recuerda cuánto tardó cada archivo para repartir mejor los hilos en la siguiente ejecución.
¿tsrs da los mismos errores que tsc? El cambio a TypeScript 7.1
Sí, siempre que lo compares con la versión de TypeScript que realmente porta, y ahí está el detalle: tsrs sigue TypeScript 7.1-dev, no 7.0.
En zod, tsrs y tsc 7.0.2 reportaron los mismos 593 errores, línea por línea. En playwright, ambos reportaron 5.664 errores, pero 20 aparecieron en otra línea y columna. En la configuración de build de hono, tsc 7.0.2 terminó limpio y tsrs reportó dos errores nuevos TS7031 (any implícito).
Después ejecutamos typescript@7.1.0-dev.20260930.4, la build del commit que porta tsrs. Su salida coincidió exactamente con tsrs en ambos repos. Las diferencias son comportamiento de TypeScript 7.1, no bugs de tsrs.
En la práctica: cambiar tsc 7.0 por tsrs en tu CI significa pasar tu type check a la semántica de 7.1-dev. Un repo que hoy está limpio puede empezar a fallar. Pruébalo primero en local y trátalo como una actualización, no como un cambio transparente.
Un detalle más para CI: con errores, tsc 7.0.2 salió con código 1 y tsrs con código 2. TypeScript 7.1-dev también devuelve 2. Los dos son distintos de cero, así que el paso de CI falla igual, pero un script que compare exactamente con 1 no.
El propio proyecto dice que quiere reducir las diferencias que quedan, como el orden en que se imprimen los diagnósticos, antes de una versión estable. Para la comparación más cercana con el compilador en Go, el README sugiere --checkerAssignment go --noLazyMembers.
tsrs vs tsc-rs: ¿qué port de TypeScript a Rust usar?
Son dos paquetes de npm distintos con nombres casi idénticos, y es fácil confundirlos.
| tsrs | tsc-rs | |
|---|---|---|
| Paquete npm | tsrs |
tsc-rs |
| Repo | oxc-project/tsrs |
pingdotgg/ts-rust |
| Detrás | Oxc, Cloudflare, VoidZero; nació en Owner.com | pingdotgg (Theo Browne) |
| Licencia | Apache-2.0 | MIT AND Apache-2.0 (npm) |
| Porta | TypeScript 7.1-dev | TypeScript 7.1-dev |
| Cómo se escribió | Agentes de IA (Claude Opus 5.5) | Agentes de IA: primero modelos de OpenAI, luego Claude Opus 5.5 |
Los dos son ports escritos por LLM a partir del mismo compilador en Go. El README de tsc-rs cuenta que el primer intento con modelos de OpenAI costó más de 400.000 dólares en tokens a precio de API y se estancó cerca del 84 por ciento de compatibilidad, y que el reinicio con Claude Opus 5.5 tomó unas dos semanas y unos 24.000 dólares.
En nuestra prueba, los dos dieron diagnósticos idénticos en los tres repos. tsrs fue alrededor de 1,6x más rápido en los repos grandes y usó cerca de la mitad de memoria; en hono empataron en tiempo y tsrs usó la mitad de memoria.
La elección puede no durar. El anuncio de Cloudflare dice que están trabajando con Theo Browne para fusionar tsc-rs y tsrs en un solo paquete. Al 20 de octubre de 2026, esa fusión está anunciada pero no publicada, y el README de ts-rust todavía no la menciona.
¿tsrs está listo para producción?
Es una versión experimental con un camino claro hacia una estable. Cloudflare la llama experimental; el README, en cambio, nombra limitaciones concretas en vez de una advertencia general, y dice que en sus pruebas sobre proyectos existentes no han encontrado un bug de corrección. El objetivo declarado es una versión estable sobre TypeScript 7.1 con 100 por ciento de conformidad.
Antes de adoptarlo:
- Issues abiertos, PRs cerrados. El tracker acepta reportes de bugs con una reproducción mínima; los mantenedores dicen que no tienen capacidad para revisar pull requests.
- Fija la versión. Cada versión del paquete indica el commit de TypeScript que sigue, así que actualizar puede cambiar los diagnósticos.
- Buen primer uso: un chequeo local o en pre-commit, o un job de CI que corra junto a
tschasta que confíes en la salida. - Hacia dónde va: Cloudflare menciona reglas de lint con información de tipos en Oxlint, y la compilación de Rust a WebAssembly es una de las razones declaradas para elegir Rust en vez de Go: correr un toolchain de TypeScript completo en el navegador o en un Worker aislado.
¿Y tú? ¿Qué usas hoy para el type check en tu CI, y cuánto tarda?
- tsc 7 (tsgo)
- bun check
- Voy a probar tsrs
- Prefiero otra opción (cuéntanos cuál)
Comenta abajo o, si este artículo te llegó por correo, responde directamente al email: tu respuesta se publica aquí.
Relacionado: bun check vs tsc: probamos el nuevo type checker de Bun en zod, playwright y hono