Bun 1.4.3 traz o bun check, um verificador de tipos TypeScript mais rápido

O Bun 1.4.3 foi lançado em 10 de outubro de 2026 e traz o bun check, um verificador de tipos TypeScript embutido no runtime. Segundo o Bun, ele roda de 3 a 6,4 vezes mais rápido que o tsc 7.0.2, o verificador da própria Microsoft, e usa de 2,2 a 4,9 vezes menos memória. Um verificador de tipos lê seu código e aponta erros de tipo sem executá-lo. Em projetos grandes, essa verificação costuma ser uma das etapas mais lentas de um pipeline de CI, o build automatizado que roda a cada pull request.

O Bun é um runtime JavaScript que também inclui um gerenciador de pacotes, um bundler e um executor de testes. A linha 1.4 é a versão que migrou o código do Bun de Zig para Rust em agosto.

O que o bun check faz

Segundo o post de lançamento do Bun 1.4.3, o bun check é um port do typescript-go. Esse é o compilador do TypeScript 7 escrito em Go, distribuído como tsc 7. A documentação do Bun diz que o comando lê o tsconfig.json, aponta os mesmos erros que o tsc do TypeScript 7 e usa todos os núcleos da CPU.

Ele só verifica. Nunca grava JavaScript, arquivos de tipos .d.ts, source maps nem arquivos .tsbuildinfo. Também não tem language server, então seu editor continua rodando a própria cópia do TypeScript. O comando sai com código 1 quando encontra um erro e com 0 quando não encontra nenhum.

O Bun relata dois testes de precisão:

• Ele passa em 51.210 de 51.210 testes da suíte de conformidade do TypeScript 7.0.2.
• Em 72 projetos de código aberto, 1.102 de 1.103 configurações deram resultados idênticos. O Bun comparou 286.267 erros e encontrou uma divergência, no vuejs/core.

A mesma verificação também roda dentro de outros comandos. bun --check, bun test --check, bun build --check e bun run --check verificam os tipos primeiro e depois fazem seu trabalho normal.

Os números do benchmark do Bun

O Bun fez sua comparação em um Mac com Apple silicon de 16 núcleos, contra o tsc 7.0.2:

Projeto	Arquivos	bun check	tsc 7.0.2	Aceleração
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

O uso de memória também caiu. No código-fonte do VS Code, o Bun mediu 2,14 GB para o bun check contra 7,97 GB para o tsc 7.0.2. O post não é totalmente consistente sobre o topo da faixa. O texto diz “de 3 a 6,4 vezes mais rápido”, enquanto o texto alternativo do gráfico fala em 3 a 7 vezes.

Um benchmark externo

Um projeto independente oferece um segundo conjunto de números. O tsrs é um port para Rust do verificador do TypeScript 7, feito pelo desenvolvedor Max Schwenk. O README dele diz que o projeto foi “escrito em grande parte por agentes de programação de IA, dirigidos e revisados por Max Schwenk”. Ele concorre com o bun check, então suas afirmações merecem a mesma cautela que as do Bun.

Na base de código do VS Code, rodando em uma máquina Linux de 64 núcleos, o tsrs relata estes tempos:

Verificador	Tempo	Pico de memória
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

O README do tsrs acrescenta uma ressalva importante. Por padrão, o tsgo usa 4 threads de verificação, enquanto o bun check usa todos os núcleos. Quando o tsrs deu 16 threads às três ferramentas no VS Code, o tsgo levou 4,54 s e o bun check levou 1,49 s. A diferença é real, mas é menor do que as configurações padrão sugerem.

O resto da versão

O Bun 1.4.3 também muda o próprio runtime:

• CPU ociosa. Servidores usam de 67% a 89% menos CPU enquanto estão ociosos. O Bun atribuiu o desperdício a um timer de coleta de lixo de um segundo que ficava ligado. Em dois minutos ociosos, um servidor Express caiu de 282 para 57 milissegundos de CPU.
• Bun.FetchSession. Uma nova API dá a um grupo de requisições suas próprias configurações de TLS, proxy e keep-alive, além de seu próprio pool de conexões.
• Bun.ModuleGraph. Uma API experimental roda muitas cópias de um app em um só processo. O post alerta que graph.dispose() “não é um sandbox de segurança”.
• node:http. Respostas grandes ficaram até 2,7 vezes mais rápidas.
• bun install. Agora ele pula tarballs que não vai instalar. Instalar o npm@10.9.2 passou de 196 tarballs para 1.
• Segurança. A versão corrige a CVE-2026-48618 na verificação de nomes de host TLS. Ela também limita a taxa de resets de streams HTTP/2 por causa da CVE-2023-44487 e da CVE-2025-8671.

O que isso significa para desenvolvedores

Para a maioria dos projetos, a troca é uma linha. A documentação do Bun mapeia tsc --noEmit para bun check e tsc -b para bun check -b. Rode bun upgrade primeiro e depois cronometre os dois comandos no seu próprio repositório. Hardware, número de threads e formato do projeto mudam o resultado.

Verifique cinco coisas antes de mudar sua CI:

• Mantenha o tsc se você publica tipos. O bun check nunca grava arquivos .d.ts, então autores de bibliotecas ainda precisam do tsc para essa etapa.
• Procure opções bloqueadas. A verificação para em configurações antigas, incluindo moduleResolution: node10, baseUrl, target: es5 e outFile.
• Yarn PnP não é suportado. Defina nodeLinker: node-modules se você usa Yarn.
• Cuidado com um script chamado check. Se o package.json define um script check, o bun check roda esse script no lugar. Nesse caso, use bun --check.
• Fixe as threads em runners compartilhados. A documentação sugere --threads 4 em máquinas de CI compartilhadas.

Seu editor ainda pode discordar do bun check, porque ele roda o próprio TypeScript. A documentação sugere instalar a versão correspondente com bun add -d typescript@$(bun -p process.versions.typescript).

As ferramentas de TypeScript continuam migrando para código nativo. A Microsoft portou o verificador para Go, o Bun portou esse port, e o tsrs o porta de novo para Rust. No mês passado, o tsgolint também levou para Go regras de lint que entendem tipos. Equipes que verificam tipos a cada commit agora têm vários verificadores rápidos para comparar entre si no próprio código.