bun check vs tsc: TypeScript type-check speed, tested

Bun 1.4.3 added bun check, a type checker built into Bun. It’s a port of TypeScript 7’s checker, reads your tsconfig.json, and, in Bun’s words, “reports the same errors as tsc, using all CPU cores.” Bun says it’s 3 to 6 times faster.

I tested both claims on two real open-source projects: Zod, which is heavy on types, and Hono, which is split into 7 TypeScript projects with project references. Each check ran three times; the numbers are the middle run.

This laptop has 4 CPU threads, and bun check uses one per thread. On a machine with more cores, expect a bigger gap.

Does it report the same errors?

On Zod, yes. tsc 7 and bun check printed the same 31 errors, identical line for line, the same codes (14 × TS6133, 8 × TS6196 and nine others) in the same places.

It matches TypeScript 7, not 6. tsc 6.0.3 reported no errors on the same project and config. If you’re still on TypeScript 6, switching to bun check also means switching to TypeScript 7’s results, so expect new errors.

On Hono, bun check reported 4 errors, all in src/hono.test.ts. tsc 7 -b reported the same 4, plus 11 in runtime-tests/bun/index.test.tsx, starting with:

error TS7016: Could not find a declaration file for module 'hono/jsx/jsx-runtime'.

That file imports Hono’s own build output, which tsc -b hasn’t produced yet when it checks that project. bun check checks against the source without building anything first, so it didn’t hit that.

The trap: a “check” script in package.json

In the Hono folder, bun check didn’t type-check anything. It printed:

Found formatting issues in 469 files (2168ms, 4 threads). Run `vp check --fix` to fix them.
error: script "check" exited with code 1

Hono’s package.json has "check": "vp check", a formatting and lint command. Inside a project with a check script, bun check runs that script instead of Bun’s type checker. Flags went to the script too: bun check -b failed with error: Unexpected argument '-b', an error from vp, not from Bun.

Zod has no check script, so there bun check type-checked normally.

cd ..
bun check -b -p hono

Project references need -b

Hono’s root tsconfig.json has "files": [] and lists the real projects under references. Plain tsc -p . checked no files at all and finished in about a second with no errors. tsc -b checks every referenced project. In bun check, -b does the same.

How I timed it

Windows 11 Pro on a laptop with 4 CPU threads, October 14, 2026. Bun 1.4.3 and TypeScript 7.0.2 and 6.0.3 from npm, installed locally. Zod (680d19f) and Hono (588ec13) were shallow clones with dependencies from bun install. Each command ran three times, and the table shows the middle time. For tsc -b, the build output was deleted before every run so each one started from scratch. Every message above is the real output.

Re-run on Linux, November 3

The same two commits on a 4-CPU GitHub Actions ubuntu-latest machine (Node 24.22.1), with Bun 1.4.3 and 1.4.4. Absolute times were lower than on my laptop, the ranking was the same:

On Zod, bun check printed the same 31 error lines as tsc 7 again. On Hono, run from the parent folder with -p hono, bun check reported the same 4 errors as before; tsc 7 -b reported 8 on Linux, not the 15 it reported on Windows, which I haven’t traced. The trap held on both versions: in a folder whose package.json has a check script, bun check ran the script and type-checked nothing. The script and the run are public.