Bun 1.4.3 añade bun check, un verificador de tipos de TypeScript más rápido

Bun 1.4.3 se publicó el 10 de octubre de 2026 y añade bun check, un verificador de tipos de TypeScript integrado en el runtime. Según Bun, es de 3 a 6,4 veces más rápido que tsc 7.0.2, el verificador de la propia Microsoft, y usa de 2,2 a 4,9 veces menos memoria. Un verificador de tipos lee su código e informa de los errores de tipo sin ejecutarlo. En proyectos grandes, esa verificación suele ser uno de los pasos más lentos de un pipeline de CI, la compilación automatizada que se ejecuta en cada pull request.

Bun es un runtime de JavaScript que también incluye un gestor de paquetes, un bundler y un ejecutor de pruebas. La rama 1.4 es la versión que trasladó el código de Bun de Zig a Rust en agosto.

Qué hace bun check

Según el anuncio de Bun 1.4.3, bun check es un port de typescript-go. Ese es el compilador de TypeScript 7 escrito en Go, que se distribuye como tsc 7. La documentación de Bun dice que el comando lee tsconfig.json, informa de los mismos errores que tsc de TypeScript 7 y usa todos los núcleos de la CPU.

Solo verifica. Nunca escribe JavaScript, archivos de tipos .d.ts, source maps ni archivos .tsbuildinfo. Tampoco tiene servidor de lenguaje, así que su editor sigue ejecutando su propia copia de TypeScript. El comando termina con el código 1 cuando encuentra un error y con 0 cuando no encuentra ninguno.

Bun informa de dos pruebas de precisión:

• Supera 51.210 de 51.210 pruebas de la suite de conformidad de TypeScript 7.0.2.
• En 72 proyectos de código abierto, 1.102 de 1.103 configuraciones dieron resultados idénticos. Bun comparó 286.267 errores y encontró una discrepancia, en vuejs/core.

La misma verificación también se ejecuta dentro de otros comandos. bun --check, bun test --check, bun build --check y bun run --check verifican primero los tipos y después hacen su trabajo normal.

Las cifras del benchmark de Bun

Bun hizo su comparación en un Mac con Apple silicon de 16 núcleos, frente a tsc 7.0.2:

Proyecto	Archivos	bun check	tsc 7.0.2	Aceleración
VS Code src	9,795	1.24 s	5.98 s	4.8x
mikro-orm	2,883	1.20 s	5.97 s	5.0x
Next.js packages/next	2,881	0.28 s	1.82 s	6.4x
Next.js root	3,547	0.42 s	1.28 s	3.1x
Storybook scripts	1,039	0.27 s	0.96 s	3.5x
Nuxt	839	0.27 s	0.80 s	3.0x
Playwright	706	0.15 s	0.64 s	4.2x

El uso de memoria también bajó. En el código fuente de VS Code, Bun midió 2,14 GB para bun check frente a 7,97 GB para tsc 7.0.2. El anuncio no es del todo coherente sobre el extremo superior del rango. Su texto dice «de 3 a 6,4 veces más rápido», mientras que el texto alternativo de su gráfico dice de 3 a 7 veces.

Un benchmark externo

Un proyecto independiente ofrece una segunda serie de cifras. tsrs es un port a Rust del verificador de TypeScript 7, obra del desarrollador Max Schwenk. Su README dice que fue «escrito en gran parte por agentes de programación de IA, dirigidos y revisados por Max Schwenk». Compite con bun check, así que sus afirmaciones merecen la misma cautela que las de Bun.

En el código de VS Code, ejecutado en una máquina Linux de 64 núcleos, tsrs informa de estos tiempos:

Verificador	Tiempo	Memoria máxima
tsc 7 (tsgo 7.0.2)	9.79 s	7.52 GiB
bun check (Bun 1.4.3 canary)	0.87 s	2.86 GiB
tsrs	0.53 s	2.64 GiB

El README de tsrs añade una advertencia importante. Por defecto, tsgo usa 4 hilos de verificación, mientras que bun check usa todos los núcleos. Cuando tsrs dio 16 hilos a las tres herramientas en VS Code, tsgo tardó 4,54 s y bun check tardó 1,49 s. La diferencia es real, pero es menor de lo que sugieren los ajustes por defecto.

El resto de la versión

Bun 1.4.3 también cambia el propio runtime:

• CPU en reposo. Los servidores usan entre un 67 % y un 89 % menos de CPU mientras están inactivos. Bun atribuyó el desperdicio a un temporizador de recolección de basura de un segundo que seguía activo. En dos minutos de inactividad, un servidor Express bajó de 282 a 57 milisegundos de CPU.
• Bun.FetchSession. Una nueva API da a un grupo de solicitudes sus propios ajustes de TLS, proxy y keep-alive, y su propio pool de conexiones.
• Bun.ModuleGraph. Una API experimental ejecuta muchas copias de una aplicación en un solo proceso. El anuncio advierte que graph.dispose() «no es un sandbox de seguridad».
• node:http. Las respuestas grandes son hasta 2,7 veces más rápidas.
• bun install. Ahora omite los tarballs que no va a instalar. Instalar npm@10.9.2 pasó de 196 tarballs a 1.
• Seguridad. La versión corrige CVE-2026-48618 en la comprobación de nombres de host TLS. También limita la tasa de reinicios de streams HTTP/2 por CVE-2023-44487 y CVE-2025-8671.

Qué significa esto para los desarrolladores

Para la mayoría de los proyectos, el cambio es una línea. La documentación de Bun hace corresponder tsc --noEmit con bun check y tsc -b con bun check -b. Ejecute primero bun upgrade y luego mida el tiempo de ambos comandos en su propio repositorio. El hardware, el número de hilos y la forma del proyecto influyen en el resultado.

Compruebe cinco cosas antes de cambiar su CI:

• Conserve tsc si publica tipos. bun check nunca escribe archivos .d.ts, así que los autores de bibliotecas siguen necesitando tsc para ese paso.
• Busque opciones bloqueadas. La verificación se detiene ante ajustes antiguos, como moduleResolution: node10, baseUrl, target: es5 y outFile.
• Yarn PnP no es compatible. Configure nodeLinker: node-modules si usa Yarn.
• Atención a un script llamado check. Si package.json define un script check, bun check ejecuta ese script en su lugar. En ese caso, use bun --check.
• Fije los hilos en runners compartidos. La documentación sugiere --threads 4 en máquinas de CI compartidas.

Su editor puede seguir sin coincidir con bun check, porque ejecuta su propio TypeScript. La documentación sugiere instalar la versión correspondiente con bun add -d typescript@$(bun -p process.versions.typescript).

Las herramientas de TypeScript siguen pasando a código nativo. Microsoft portó el verificador a Go, Bun portó ese port y tsrs lo vuelve a portar a Rust. El mes pasado, tsgolint también llevó a Go las reglas de lint que tienen en cuenta los tipos. Los equipos que verifican tipos en cada commit tienen ahora varios verificadores rápidos para comparar entre sí con su propio código.