bun check, o verificador de tipos TypeScript que chegou com Bun 1.4.3, foi entre 2,7 e 4,5 vezes mais rápido que tsc 7.0.2 em nossos testes com zod e Playwright, e reportou exatamente os mesmos erros. Em um projeto pequeno, porém, tsc venceu.
yoDEV Tested · 14 de outubro de 2026
Comparamosbun checkde Bun 1.4.3 comtsc7.0.2 em zod, Playwright e Hono, em um container Linux x86_64 com 2 vCPU e 7 GB de RAM (mediana de cinco execuções). Os resultados que reportamos como nossos saem desse teste.
Bun 1.4.3 foi publicado em 10 de outubro de 2026 e inclui bun check sem necessidade de instalar o pacote typescript. Colocamos à prova contra tsc em três projetos open source reais, em uma máquina modesta, para ver o que resta das cifras oficiais fora do benchmark de Bun.
O que é bun check e o que tem a ver com TypeScript 7?
bun check é um port de typescript-go, a reescrita em Go do TypeScript que Microsoft lançou como TypeScript 7, compilado dentro do binário de Bun. Lê seu tsconfig.json, reporta os mesmos erros que tsc do TypeScript 7 e usa todos os núcleos da CPU. As declarações lib.*.d.ts do TypeScript (Array, Promise, o DOM) vêm incluídas, então o projeto não precisa de typescript em node_modules para que a verificação funcione.
Se Bun é novo para você: é um runtime de JavaScript e TypeScript que também traz gerenciador de pacotes, bundler e test runner em um único executável. bun check é a peça mais recente desse kit.
Só verifica tipos. Não gera JavaScript, arquivos .d.ts nem source maps, e não inclui um language server. Termina com código 1 se encontrar um erro e com 0 se não encontrar nenhum.
Para confirmar com qual versão do TypeScript coincide seu Bun:
bun -p process.versions.typescript
Em Bun 1.4.3 retorna 7.0.2. Se você quer o contexto dessa versão, cobrimos em TypeScript 7.0 já está em GA.
bun check é mais rápido que tsc?
Segundo as cifras de Bun, é entre 3 e 6,4 vezes mais rápido que tsc 7.0.2 e usa entre 2,2 e 4,9 vezes menos memória. São benchmarks próprios de Bun, medidos em um Mac com Apple silicon de 16 núcleos sobre oito projetos, desde o src do VS Code (9.795 arquivos) até packages/react de lit (6 arquivos), e ninguém os reproduziu de forma independente.
Então reproduzimos uma parte em uma máquina deliberadamente modesta: um container Linux x86_64 com 2 vCPU e 7 GB de RAM. Usamos bun@1.4.3 e typescript@7.0.2 do npm, clonamos três repos da própria lista de testes de Bun, descartamos uma execução de aquecimento e tomamos a mediana de cinco execuções (dez em Hono).
| Projeto | tsc 7.0.2 |
bun check |
Resultado |
|---|---|---|---|
| zod, 604 erros, sem dependências instaladas | 5,93 s · 1.124 MB | 1,31 s · 191 MB | 4,5x mais rápido, 5,9x menos memória |
| Playwright, 5.692 erros, sem dependências instaladas | 3,11 s · 572 MB | 1,13 s · 198 MB | 2,7x mais rápido, 2,9x menos memória |
Hono, tsconfig.build.json, 188 arquivos, dependências instaladas, sem erros |
0,32 s · 98 MB | 0,47 s · 152 MB | tsc 1,4x mais rápido |
Três coisas se destacam.
A vantagem se mantém com dois núcleos. As cifras de Bun vêm de uma máquina de 16 núcleos, então seria de esperar que a diferença desaparecesse em um runner de CI pequeno. Não foi assim. Também forçamos ambas as ferramentas a um único thread em zod (bun check --threads 1 contra tsc --checkers 1): 2,33 s contra 5,50 s, ainda 2,4 vezes mais rápido. O ganho não vem só do paralelismo.
Os projetos pequenos não se beneficiam. Com a configuração de build de Hono, de 188 arquivos, bun check foi mais lento e usou mais memória. Executá-lo com --timing explica o motivo: passou uns 100 ms carregando 364 arquivos antes de verificar 188 em 328 ms. Em um projeto que tsc revisa em um terço de segundo, esse custo fixo decide o resultado. A tabela publicada por Bun não tem nenhum caso onde perca, mas nenhum de seus projetos é ao mesmo tempo pequeno, com dependências instaladas e em uma máquina de poucos núcleos.
Em repos grandes, a memória é o maior ganho. Em zod, o pico de memória baixou de 1,1 GB para menos de 200 MB. Em um runner de CI compartilhado isso importa tanto quanto os segundos.
bun check reporta os mesmos erros que tsc?
Em nossos testes, sim. O post de Bun propõe um teste de três linhas, e o executamos em cada projeto:
bunx -p typescript@7.0.2 tsc --noEmit --pretty false > tsc.txt
bun check --no-pretty > bun.txt
diff tsc.txt bun.txt
Em zod e Playwright, os 6.296 erros coincidiram em arquivo, linha, coluna, código e mensagem. A única diferença foi cosmética: quando falta @types/node, tsc sugere npm i --save-dev @types/node e bun check sugere bun add -d @types/node. A raiz mal configurada de Hono (7 erros) e sua configuração de build limpa também coincidiram.
Bun afirma que passa os 51.210 testes da suite de conformidade do TypeScript 7.0.2, e que comparou sua saída com a de tsc em 72 repositórios open source mal configurados de propósito, com uma única discrepância em 1.103 configurações, em vuejs/core. São testes do próprio Bun; os nossos cobrem muito menos terreno, mas não encontraram nada que os contradiga. Bun considera qualquer diferença com tsc 7 um bug e pede reportá-la como issue no GitHub.
Como substituir tsc --noEmit por bun check?
Na maioria dos projetos só muda o comando. A documentação de Bun os mapeia assim:
| Em vez de | Execute |
|---|---|
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 |
Se ainda não usa os tipos de Bun, adicione-os primeiro:
bun add -d @types/bun
e declare-os em tsconfig.json:
{
"compilerOptions": {
"types": ["bun"]
}
}
Desde TypeScript 6, os pacotes de node_modules/@types só contam se types os incluir. Vimos isso em nosso próprio teste: em uma pasta vazia, sem node_modules, bun check detectou o erro de tipos, marcou também console como desconhecido e mostrou a sugestão bun add -d @types/bun.
No GitHub Actions
Este é o workflow da documentação 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
No GitHub Actions, bun check imprime além disso um workflow command para cada erro, então os erros aparecem como anotações no diff do pull request sem necessidade de um problem matcher. Quando a saída não é um terminal, usa o formato de uma linha de tsc --pretty false, de modo que os scripts escritos para tsc continuam funcionando. Em runners compartilhados, --threads 4 limita a quantidade de threads.
Dois detalhes de CI que convém conhecer: bun check não escreve .tsbuildinfo, então não há cache que guardar e cada execução revisa todo o projeto; e uma execução que não encontra nada que revisar termina com código 1, de modo que um job apontado ao diretório errado falha em vez de passar.
Antes de cada commit
Um hook do Git simples:
#!/bin/sh
bun check
guardado como .git/hooks/pre-commit e com permissões de execução via chmod +x .git/hooks/pre-commit. Com lint-staged, "*.{ts,tsx}": "bun check" revisa só os arquivos em stage e o que importam, e mesmo assim carrega seu tsconfig.json, algo que tsc não faz quando lhe passa nomes de arquivo. A documentação de Bun recomenda manter igualmente a verificação completa em CI, porque uma mudança em um arquivo pode quebrar outro que o importa.
Bun vs Node: você precisa usar Bun como runtime para usar bun check?
Não. bun check só lê seu tsconfig.json e busca pacotes em node_modules, igual que tsc; não executa seu código. zod e Playwright, dois dos projetos que testamos, não usam Bun como runtime, e bun check os revisou com seu tsconfig.json tal qual, com os mesmos resultados que tsc. Você pode continuar executando sua aplicação com Node e usar Bun só como verificador de tipos em CI.
A exceção é Yarn Plug’n’Play, que bun check não suporta: a documentação indica configurar nodeLinker: node-modules em .yarnrc.yml.
bun check substitui TypeScript no VS Code?
Não. Seu editor executa sua própria cópia do TypeScript, e bun check não tem language server. Para que editor e CI coincidam, a documentação de Bun sugere instalar exatamente a versão com a qual coincide bun check:
bun add -d typescript@$(bun -p process.versions.typescript)
e depois, no VS Code, executar TypeScript: Select TypeScript Version e escolher Use Workspace Version. Repita ao atualizar Bun, porque uma versão nova pode coincidir com um TypeScript mais recente. E conserve tsc se publica arquivos .d.ts: bun check nunca os gera.
O que muda em seu tsconfig com TypeScript 7?
bun check se comporta como TypeScript 7 sem importar qual versão você tenha instalada, então se vem do TypeScript 5 vai notar as mudanças de padrão: strict está ativado, types está vazio e os imports de efeito colateral (como import "./index.css") também são verificados. Além disso, opções como baseUrl, "moduleResolution": "node" e "target": "es5" já não existem. Se seu tsconfig.json usa uma opção eliminada, bun check a reporta e se detém antes de revisar nenhum arquivo, igual que tsc 7.
A documentação de Bun indica o que usar em cada caso: "moduleResolution": "bundler" (ou "nodenext" para código que Node executa sem bundler), eliminar baseUrl e começar cada entrada de paths com ./, e "target": "es2015" ou posterior.
O que pode falhar ao mudar para bun check?
Seu projeto já tem um script check. Este foi o que nos surpreendeu. O package.json de Hono define "check": "vp check", e bun check executou esse script em vez de verificar tipos. Bun o documenta: seu script tem prioridade. Use bun --check para chegar ao verificador de tipos, ou chame typecheck a seu próprio script.
bun --check não aceita -p como projeto. No nível superior de Bun, -p significa “print”. Quando executamos bun --check -p tsconfig.build.json para esquivar o script de Hono, Bun avaliou o nome do arquivo como código e reportou Cannot find name 'tsconfig'. Se você precisa de um tsconfig específico, renomeie o script que choca e use bun check -p.
A saída muda dentro de agentes de IA. Quando está definida AGENT=1, CLAUDECODE=1 ou REPL_ID=1, bun check imprime cada erro como um bloco etiquetado pensado para que o leia um modelo. Nosso container tinha CLAUDECODE=1, e isso foi o que vimos até removê-la. Útil dentro de um agente, surpreendente em um log de CI.
Vale a pena mudar de tsc para bun check?
Se sua CI verifica tipos em um projeto de alguns milhares de arquivos, sim: bun check é a melhoria de velocidade mais barata disponível hoje. Mude um comando, os erros continuam sendo idênticos, e em nossa máquina de dois núcleos reduziu a etapa entre 2,7 e 4,5 vezes e sua memória em dois terços ou mais. Se seu projeto se verifica em menos de meio segundo, não vale a pena: aí tsc 7 foi mais rápido. Em qualquer caso, execute o diff de três linhas de Bun sobre seu próprio repo antes de mudar. Leva um minuto e converte as cifras de Bun nas suas.
Ao momento de publicar esta nota, as cifras de velocidade e a afirmação de conformidade correspondem a TypeScript 7.0.2 e mudarão com a próxima versão do TypeScript.
E você? Quanto leva hoje a etapa de verificação de tipos em seu pipeline de CI?
- tsc do TypeScript 5 ou 6
- tsc do TypeScript 7
- bun check
- Prefiro outra opção (conte-nos qual)
Comente abaixo ou, se este artigo chegou a você por email, responda diretamente ao email: sua resposta é publicada aqui.
Relacionado: TypeScript 7.0 já está em GA