Bun 1.4.3 ships a type checker that beats tsc. Here's where it wins, and where it doesn't.

Bun 1.4.3 landed on October 10, and the headline feature is bun check, a TypeScript type checker built straight into the Bun binary. It reads your existing tsconfig.json, reports the same errors tsc does, and uses every CPU core. You don't even need the typescript package installed. On Bun's own benchmarks, run on a 16-core Apple silicon Mac, it finishes type checking between 3x and 6.4x faster than tsc 7.0.2 while using 2.2x to 4.9x less memory. VS Code's src directory, nearly 10,000 files, dropped from 5.98 seconds to 1.24 seconds.

The accuracy story is the part that caught our attention. bun check is a port of typescript-go, Microsoft's Go rewrite of the compiler, and it passes all 51,210 tests in TypeScript 7.0.2's conformance suite. Bun also ran it against 72 open-source projects and compared its output to tsc across 1,103 configurations. It matched on 1,102 of them. The single mismatch was one error in vuejs/core. A reimplementation of a famously fiddly type system agreeing with the original almost everywhere is rare, and it's the reason this is worth taking seriously rather than filing under "another fast-but-wrong tool."

So should you switch? Here's the honest version, because the benchmark numbers hide an important catch.

No incremental mode, and why that decides everything

bun check keeps no state between runs. It writes no .tsbuildinfo file, so every run is a cold run. That is exactly why it wins on CI runners and fresh checkouts, which always start cold anyway, and it's also why tsc can still beat it on your laptop.

Independent testers confirmed both sides. Scrydon moved their monorepo's type-check gate onto it, and a full cold check of 104 projects fell from 124.9 seconds to roughly 51 to 68 seconds, with peak memory down about a third. But on a warm re-check after a one-line change, tsc's incremental mode answered in 0.81 seconds against bun check's 1.57. On a small project, Hono's 188-file build config, tsc was actually faster, because bun check pays a fixed startup cost loading its lib files before it checks anything.

From our own work this maps cleanly onto where it belongs. When we build cloud-native PHP and Node services for enterprise clients, the type-check step in CI is often the slowest gate in the pipeline, and it's almost always a cold run on a fresh container. That's the sweet spot. Cutting that step by half, with identical errors and lower memory, is a real win, and it means teams can stop capping type-check concurrency just to avoid blowing out a runner's RAM. On a developer's machine, where someone re-checks the same package in a tight loop, warm tsc is still the better tool. These aren't competing claims. They describe two different workloads.

It does not replace TypeScript in your editor

One thing to be clear about: bun check does no language-server work, so autocomplete and go-to-definition still run the typescript package your editor already uses. It also only checks. It emits no JavaScript and no .d.ts files, so if you publish a library you still need tsc to generate declarations. Treat it as a faster CI gate, not a full replacement.

There's a security angle worth a line too. In our pentesting engagements we keep seeing supply-chain risk creep in through build tooling that nobody audits. bun check needing no typescript install in the checking step is one fewer dependency resolved at CI time, and because it reports byte-identical errors, you can adopt it without weakening the gate that catches real bugs. That's the kind of change we like: fewer moving parts, same guarantees.

The five-minute test before you commit to it

The actionable part is small and low-risk. Before you rewrite a single CI config, run Bun's own diff test on your repo:

bunx -p typescript@7.0.2 tsc --noEmit --pretty false > tsc.txt
bun check --no-pretty > bun.txt
diff tsc.txt bun.txt

If the diff is empty, your errors match and you can swap tsc --noEmit for bun check in CI with confidence. If it isn't empty, you've found one of the rare edge cases, and now you know before it bites you in a release. One field report flagged a naming clash worth checking first: if your package.json already defines a script named check, running bun check inside that folder may run your script instead of the type checker, so point it at your config explicitly or run it from another directory.

We've spent years tuning build and test pipelines for web and mobile teams, from PHP and Docker backends to native iOS and Android apps, and the pattern is always the same. The fastest pipeline is the one that does less work, keeps the same safety checks, and fails loudly when something drifts. bun check fits that brief for a lot of CI setups, with the honest asterisk that it isn't for every workload.

If a slow type-check gate in CI sounds familiar, let's talk. We help teams speed up their development pipelines without dropping the checks that actually catch bugs.