Bun 1.4.3 incluye un verificador de tipos que supera a tsc. Aquí dónde gana y dónde no.

Bun 1.4.3 se publicó el 10 de octubre y su característica principal es bun check, un verificador de tipos de TypeScript integrado directamente en el binario de Bun. Lee su tsconfig.json existente, reporta los mismos errores que tsc y utiliza todos los núcleos del procesador. Ni siquiera necesita tener instalado el paquete typescript. En los propios benchmarks de Bun, ejecutados en un Mac Apple silicon de 16 núcleos, completa la verificación de tipos entre 3x y 6,4x más rápido que tsc 7.0.2, utilizando entre 2,2x y 4,9x menos memoria. El directorio src de VS Code, con casi 10.000 archivos, pasó de 5,98 segundos a 1,24 segundos.

La precisión fue lo que más llamó nuestra atención. bun check es un port de typescript-go, la reescritura en Go del compilador por parte de Microsoft, y supera los 51.210 tests de la suite de conformidad de TypeScript 7.0.2. Bun también lo ejecutó contra 72 proyectos de código abierto y comparó su resultado con tsc en 1.103 configuraciones. Coincidió en 1.102 de ellas. La única discrepancia fue un error en vuejs/core. Una reimplementación de un sistema de tipos conocidamente complejo que coincide con el original en casi todos los casos es algo excepcional, y es la razón por la que merece tomarse en serio en lugar de clasificarla como «otra herramienta rápida pero incorrecta».

¿Debería cambiar? Esta es la versión honesta, porque los números del benchmark ocultan un detalle importante.

Sin modo incremental, y por qué eso lo decide todo

bun check no mantiene estado entre ejecuciones. No escribe ningún archivo .tsbuildinfo, por lo que cada ejecución parte de cero. Esa es exactamente la razón por la que gana en los runners de CI y en checkouts nuevos, que siempre arrancan en frío, y también por la que tsc puede seguir siendo más rápido en su equipo.

Testers independientes confirmaron ambos aspectos. Scrydon migró la verificación de tipos de su monorepo a él y una verificación en frío completa de 104 proyectos bajó de 124,9 segundos a aproximadamente 51-68 segundos, con el pico de memoria reducido en cerca de un tercio. Pero en una reverificación en caliente tras un cambio de una línea, el modo incremental de tsc respondió en 0,81 segundos frente a los 1,57 de bun check. En un proyecto pequeño, la configuración de 188 archivos de Hono, tsc fue en realidad más rápido, porque bun check paga un coste fijo de arranque al cargar sus archivos de librería antes de verificar nada.

Desde nuestra propia experiencia, esto encaja perfectamente con dónde corresponde usarlo. Cuando desarrollamos servicios PHP y Node nativos en la nube para clientes empresariales, el paso de verificación de tipos en CI suele ser la etapa más lenta del pipeline, y casi siempre se ejecuta en frío en un contenedor nuevo. Ese es el punto óptimo. Reducir esa etapa a la mitad, con errores idénticos y menor uso de memoria, es una mejora real, y significa que los equipos pueden dejar de limitar la concurrencia de verificación de tipos solo para no saturar la RAM del runner. En el equipo de un desarrollador, donde se reverifica el mismo paquete en un bucle cerrado, tsc en caliente sigue siendo la mejor opción. No son afirmaciones contradictorias. Describen dos cargas de trabajo diferentes.

No reemplaza TypeScript en su editor

Algo que debe quedar claro: bun check no realiza ningún trabajo de servidor de lenguaje, por lo que el autocompletado y la navegación al código siguen usando el paquete typescript que ya utiliza su editor. Además, solo verifica. No emite JavaScript ni archivos .d.ts, por lo que si publica una librería seguirá necesitando tsc para generar las declaraciones. Trátelo como una puerta de CI más rápida, no como un reemplazo completo.

También hay un aspecto de seguridad que merece mención. En nuestros trabajos de pentesting seguimos viendo cómo el riesgo de la cadena de suministro se cuela a través de herramientas de construcción que nadie audita. Que bun check no necesite una instalación de typescript en el paso de verificación es una dependencia menos resuelta en tiempo de CI, y como reporta errores byte a byte idénticos, puede adoptarlo sin debilitar la barrera que detecta errores reales. Ese es el tipo de cambio que nos gusta: menos piezas móviles, las mismas garantías.

La prueba de cinco minutos antes de comprometerse

La parte práctica es pequeña y de bajo riesgo. Antes de reescribir ninguna configuración de CI, ejecute la propia prueba de diferencias de Bun en su repositorio:

bunx -p typescript@7.0.2 tsc --noEmit --pretty false > tsc.txt
bun check --no-pretty > bun.txt
diff tsc.txt bun.txt

Si el diff está vacío, sus errores coinciden y puede sustituir tsc --noEmit por bun check en CI con confianza. Si no está vacío, ha encontrado uno de los raros casos extremos, y ahora lo sabe antes de que le sorprenda en una versión. Un informe de campo señaló un conflicto de nombres que vale la pena verificar primero: si su package.json ya define un script llamado check, ejecutar bun check dentro de esa carpeta puede ejecutar su script en lugar del verificador de tipos, así que apúntelo explícitamente a su configuración o ejecútelo desde otro directorio.

Llevamos años optimizando pipelines de construcción y pruebas para equipos web y móviles, desde backends PHP y Docker hasta aplicaciones nativas de iOS y Android, y el patrón es siempre el mismo. El pipeline más rápido es el que hace menos trabajo, mantiene las mismas verificaciones de seguridad y falla de forma clara cuando algo se desvía. bun check cumple ese requisito para muchas configuraciones de CI, con el asterisco honesto de que no es para todas las cargas de trabajo.

Si una puerta de verificación de tipos lenta en CI le resulta familiar, hablemos. Ayudamos a los equipos a acelerar sus pipelines de desarrollo sin eliminar las verificaciones que realmente detectan errores.