bun check, el type checker de TypeScript que llegó con Bun 1.4.3, fue entre 2,7 y 4,5 veces más rápido que tsc 7.0.2 en nuestras pruebas con zod y Playwright, y reportó exactamente los mismos errores. En un proyecto pequeño, en cambio, tsc ganó.
yoDEV Tested · 14 de octubre de 2026
Comparamosbun checkde Bun 1.4.3 contsc7.0.2 en zod, Playwright y Hono, en un contenedor Linux x86_64 con 2 vCPU y 7 GB de RAM (mediana de cinco ejecuciones). Los resultados que reportamos como nuestros salen de esa prueba.
Bun 1.4.3 se publicó el 10 de octubre de 2026 e incluye bun check sin necesidad de instalar el paquete typescript. Lo pusimos a prueba contra tsc en tres proyectos open source reales, en una máquina modesta, para ver qué queda de las cifras oficiales fuera del benchmark de Bun.
¿Qué es bun check y qué tiene que ver con TypeScript 7?
bun check es un port de typescript-go, la reescritura en Go de TypeScript que Microsoft lanzó como TypeScript 7, compilado dentro del binario de Bun. Lee tu tsconfig.json, reporta los mismos errores que tsc de TypeScript 7 y usa todos los núcleos de la CPU. Las declaraciones lib.*.d.ts de TypeScript (Array, Promise, el DOM) vienen incluidas, así que el proyecto no necesita typescript en node_modules para que el chequeo funcione.
Si Bun es nuevo para ti: es un runtime de JavaScript y TypeScript que también trae gestor de paquetes, bundler y test runner en un solo ejecutable. bun check es la pieza más reciente de ese kit.
Solo verifica tipos. No genera JavaScript, archivos .d.ts ni source maps, y no incluye un language server. Termina con código 1 si encuentra un error y con 0 si no encuentra ninguno.
Para confirmar con qué versión de TypeScript coincide tu Bun:
bun -p process.versions.typescript
En Bun 1.4.3 devuelve 7.0.2. Si quieres el contexto de esa versión, lo cubrimos en TypeScript 7.0 ya está en GA.
¿bun check es más rápido que tsc?
Según las cifras de Bun, es entre 3 y 6,4 veces más rápido que tsc 7.0.2 y usa entre 2,2 y 4,9 veces menos memoria. Son benchmarks propios de Bun, medidos en una Mac con Apple silicon de 16 núcleos sobre ocho proyectos, desde el src de VS Code (9.795 archivos) hasta packages/react de lit (6 archivos), y nadie los ha reproducido de forma independiente.
Así que reprodujimos una parte en una máquina deliberadamente modesta: un contenedor Linux x86_64 con 2 vCPU y 7 GB de RAM. Usamos bun@1.4.3 y typescript@7.0.2 desde npm, clonamos tres repos de la propia lista de pruebas de Bun, descartamos una ejecución de calentamiento y tomamos la mediana de cinco ejecuciones (diez en Hono).
| Proyecto | tsc 7.0.2 |
bun check |
Resultado |
|---|---|---|---|
| zod, 604 errores, sin dependencias instaladas | 5,93 s · 1.124 MB | 1,31 s · 191 MB | 4,5x más rápido, 5,9x menos memoria |
| Playwright, 5.692 errores, sin dependencias instaladas | 3,11 s · 572 MB | 1,13 s · 198 MB | 2,7x más rápido, 2,9x menos memoria |
Hono, tsconfig.build.json, 188 archivos, dependencias instaladas, sin errores |
0,32 s · 98 MB | 0,47 s · 152 MB | tsc 1,4x más rápido |
Tres cosas destacan.
La ventaja se mantiene con dos núcleos. Las cifras de Bun vienen de una máquina de 16 núcleos, así que cabría esperar que la diferencia desapareciera en un runner de CI pequeño. No fue así. También forzamos ambas herramientas a un solo hilo en zod (bun check --threads 1 contra tsc --checkers 1): 2,33 s frente a 5,50 s, todavía 2,4 veces más rápido. La ganancia no viene solo del paralelismo.
Los proyectos pequeños no se benefician. Con la configuración de build de Hono, de 188 archivos, bun check fue más lento y usó más memoria. Ejecutarlo con --timing explica el motivo: pasó unos 100 ms cargando 364 archivos antes de verificar 188 en 328 ms. En un proyecto que tsc revisa en un tercio de segundo, ese costo fijo decide el resultado. La tabla publicada por Bun no tiene ningún caso donde pierda, pero ninguno de sus proyectos es a la vez pequeño, con dependencias instaladas y en una máquina de pocos núcleos.
En repos grandes, la memoria es la mayor ganancia. En zod, el pico de memoria bajó de 1,1 GB a menos de 200 MB. En un runner de CI compartido eso importa tanto como los segundos.
¿bun check reporta los mismos errores que tsc?
En nuestras pruebas, sí. El post de Bun propone una prueba de tres líneas, y la ejecutamos en cada proyecto:
bunx -p typescript@7.0.2 tsc --noEmit --pretty false > tsc.txt
bun check --no-pretty > bun.txt
diff tsc.txt bun.txt
En zod y Playwright, los 6.296 errores coincidieron en archivo, línea, columna, código y mensaje. La única diferencia fue cosmética: cuando falta @types/node, tsc sugiere npm i --save-dev @types/node y bun check sugiere bun add -d @types/node. La raíz mal configurada de Hono (7 errores) y su configuración de build limpia también coincidieron.
Bun afirma que pasa los 51.210 tests de la suite de conformidad de TypeScript 7.0.2, y que comparó su salida con la de tsc en 72 repositorios open source mal configurados a propósito, con una sola discrepancia en 1.103 configuraciones, en vuejs/core. Son pruebas del propio Bun; las nuestras cubren mucho menos terreno, pero no encontraron nada que las contradiga. Bun considera cualquier diferencia con tsc 7 un bug y pide reportarla como issue en GitHub.
¿Cómo reemplazar tsc --noEmit por bun check?
En la mayoría de los proyectos solo cambia el comando. La documentación de Bun los mapea así:
| En lugar de | Ejecuta |
|---|---|
tsc --noEmit |
bun check |
tsc --noEmit -p packages/server |
bun check -p packages/server |
tsc -b |
bun check -b |
tsc --noEmit && bun test |
bun test --check |
tsc --noEmit && bun build ./app.ts |
bun build --check ./app.ts |
Si todavía no usas los tipos de Bun, agrégalos primero:
bun add -d @types/bun
y decláralos en tsconfig.json:
{
"compilerOptions": {
"types": ["bun"]
}
}
Desde TypeScript 6, los paquetes de node_modules/@types solo cuentan si types los incluye. Lo vimos en nuestra propia prueba: en una carpeta vacía, sin node_modules, bun check detectó el error de tipos, marcó también console como desconocido y mostró la sugerencia bun add -d @types/bun.
En GitHub Actions
Este es el workflow de la documentación de Bun:
name: Type check
on: [push, pull_request]
jobs:
typecheck:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: oven-sh/setup-bun@v2
- run: bun install --frozen-lockfile
- run: bun check
En GitHub Actions, bun check imprime además un workflow command por cada error, así que los errores aparecen como anotaciones en el diff del pull request sin necesidad de un problem matcher. Cuando la salida no es una terminal, usa el formato de una línea de tsc --pretty false, de modo que los scripts escritos para tsc siguen funcionando. En runners compartidos, --threads 4 limita la cantidad de hilos.
Dos detalles de CI que conviene conocer: bun check no escribe .tsbuildinfo, así que no hay caché que guardar y cada ejecución revisa todo el proyecto; y una ejecución que no encuentra nada que revisar termina con código 1, de modo que un job apuntado al directorio equivocado falla en lugar de pasar.
Antes de cada commit
Un hook de Git simple:
#!/bin/sh
bun check
guardado como .git/hooks/pre-commit y con permisos de ejecución mediante chmod +x .git/hooks/pre-commit. Con lint-staged, "*.{ts,tsx}": "bun check" revisa solo los archivos en stage y lo que importan, y aun así carga tu tsconfig.json, algo que tsc no hace cuando le pasas nombres de archivo. La documentación de Bun recomienda mantener igualmente el chequeo completo en CI, porque un cambio en un archivo puede romper otro que lo importa.
Bun vs Node: ¿necesitas usar Bun como runtime para usar bun check?
No. bun check solo lee tu tsconfig.json y busca paquetes en node_modules, igual que tsc; no ejecuta tu código. zod y Playwright, dos de los proyectos que probamos, no usan Bun como runtime, y bun check los revisó con su tsconfig.json tal cual, con los mismos resultados que tsc. Puedes seguir ejecutando tu aplicación con Node y usar Bun solo como type checker en CI.
La excepción es Yarn Plug’n’Play, que bun check no soporta: la documentación indica configurar nodeLinker: node-modules en .yarnrc.yml.
¿bun check reemplaza a TypeScript en VS Code?
No. Tu editor ejecuta su propia copia de TypeScript, y bun check no tiene language server. Para que editor y CI coincidan, la documentación de Bun sugiere instalar exactamente la versión con la que coincide bun check:
bun add -d typescript@$(bun -p process.versions.typescript)
y después, en VS Code, ejecutar TypeScript: Select TypeScript Version y elegir Use Workspace Version. Repítelo al actualizar Bun, porque una versión nueva puede coincidir con un TypeScript más reciente. Y conserva tsc si publicas archivos .d.ts: bun check nunca los genera.
¿Qué cambia en tu tsconfig con TypeScript 7?
bun check se comporta como TypeScript 7 sin importar qué versión tengas instalada, así que si vienes de TypeScript 5 vas a notar los cambios de default: strict está activado, types está vacío y los imports de efecto secundario (como import "./index.css") también se verifican. Además, opciones como baseUrl, "moduleResolution": "node" y "target": "es5" ya no existen. Si tu tsconfig.json usa una opción eliminada, bun check la reporta y se detiene antes de revisar ningún archivo, igual que tsc 7.
La documentación de Bun indica qué usar en cada caso: "moduleResolution": "bundler" (o "nodenext" para código que Node ejecuta sin bundler), eliminar baseUrl y empezar cada entrada de paths con ./, y "target": "es2015" o posterior.
¿Qué puede fallar al cambiar a bun check?
Tu proyecto ya tiene un script check. Este fue el que nos sorprendió. El package.json de Hono define "check": "vp check", y bun check ejecutó ese script en lugar de verificar tipos. Bun lo documenta: tu script tiene prioridad. Usa bun --check para llegar al type checker, o llama typecheck a tu propio script.
bun --check no acepta -p como proyecto. En el nivel superior de Bun, -p significa “print”. Cuando ejecutamos bun --check -p tsconfig.build.json para esquivar el script de Hono, Bun evaluó el nombre del archivo como código y reportó Cannot find name 'tsconfig'. Si necesitas un tsconfig específico, renombra el script que choca y usa bun check -p.
La salida cambia dentro de agentes de IA. Cuando está definida AGENT=1, CLAUDECODE=1 o REPL_ID=1, bun check imprime cada error como un bloque etiquetado pensado para que lo lea un modelo. Nuestro contenedor tenía CLAUDECODE=1, y eso fue lo que vimos hasta quitarla. Útil dentro de un agente, sorprendente en un log de CI.
¿Vale la pena cambiar de tsc a bun check?
Si tu CI verifica tipos en un proyecto de algunos miles de archivos, sí: bun check es la mejora de velocidad más barata disponible hoy. Cambia un comando, los errores siguen siendo idénticos, y en nuestra máquina de dos núcleos redujo el paso entre 2,7 y 4,5 veces y su memoria en dos tercios o más. Si tu proyecto se verifica en menos de medio segundo, no vale la pena: ahí tsc 7 fue más rápido. En cualquier caso, ejecuta el diff de tres líneas de Bun sobre tu propio repo antes de cambiar. Toma un minuto y convierte las cifras de Bun en las tuyas.
Al momento de publicar esta nota, las cifras de velocidad y la afirmación de conformidad corresponden a TypeScript 7.0.2 y cambiarán con la próxima versión de TypeScript.
¿Y tú? ¿Cuánto tarda hoy el paso de type check en tu pipeline de CI?
- tsc de TypeScript 5 o 6
- tsc de TypeScript 7
- bun check
- 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: TypeScript 7.0 ya está en GA