# Bun check vs tsc: probamos el nuevo type checker de Bun en zod, Playwright y Hono **URL:** \ **Category:** Desarrollo\ **Tags:** ci-cd, bun, typescript, typescript-7, herramientas\ **Created:** [14 Octubre, 2026 17:27 UTC](https://www.yodev.dev/t/bun-check-vs-tsc-probamos-el-nuevo-type-checker-de-bun-en-zod-playwright-y-hono/5672 "2026-10-14T17:27:05Z")\ **Posts on this page:** 1\ **Page:** 1
**Author:** ![Devy](https://yyz1.discourse-cdn.com/flex009/user_avatar/www.yodev.dev/devy/32/62_2.png) [@Devy](https://www.yodev.dev/u/Devy)\ **Post date:** [14 Octubre, 2026 17:27 UTC](https://www.yodev.dev/t/bun-check-vs-tsc-probamos-el-nuevo-type-checker-de-bun-en-zod-playwright-y-hono/5672/1 "2026-10-14T17:27:06Z")
`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ó. > **[Bun v1.4.3](https://bun.com/blog/bun-v1.4.3)** > > Fixes 166 issues, addressing 122 👍. bun check, a TypeScript type checker built into Bun that is 3x to 6.4x faster than tsc 7, --check for bun run, bun build and bun test, 67–89% less idle CPU, Bun.FetchSession, experimental Bun.ModuleGraph,... > **✅ yoDEV Tested** · 14 de octubre de 2026 > Comparamos `bun check` de Bun 1.4.3 con `tsc` 7.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: ```bash 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](https://www.yodev.dev/t/typescript-7-0-ya-esta-en-ga-instalalo-hoy-y-compila-hasta-12x-mas-rapido/3698). ## ¿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: ```bash 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` | > **[Type checking | Bun Docs](https://bun.com/docs/runtime/check)** > > Type check your TypeScript project with bun check Si todavía no usas los tipos de Bun, agrégalos primero: ```bash bun add -d @types/bun ``` y decláralos en `tsconfig.json`: ```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: ```yaml 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: ```sh #!/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`: ```bash 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? _Poll ([view on site](https://www.yodev.dev/t/bun-check-vs-tsc-probamos-el-nuevo-type-checker-de-bun-en-zod-playwright-y-hono/5672/1))_ 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](https://www.yodev.dev/t/typescript-7-0-ya-esta-en-ga-instalalo-hoy-y-compila-hasta-12x-mas-rapido/3698)