Bun 1.4.3 Claims Type Checking More Than Three Times Faster Than TypeScript 7

A pull request changes a shared TypeScript interface. The application starts locally and the tests pass, so the developer pushes the branch. But CI fails. Another package in the repository was still using the old interface.

TypeScript code can run successfully without being type-correct. Teams need a separate type-checking step, and how long it takes affects how often developers run it.

Bun 1.4.3, released on October 10, 2026, puts this issue at the center of the release. According to the supplied report, Anthropic’s JavaScript runtime now includes a TypeScript type checker available through bun check. The claims are substantial: more than three times the speed of TypeScript 7, with memory usage ranging from roughly half to a quarter, or even less.

Those figures warrant evaluation. They alone, however, should not be grounds for replacing existing CI checks.

What Bun 1.4.3 Adds#

Bun already supports loading TypeScript, transpiling it into JavaScript, and executing the result. Type checking serves a different purpose.

Transpilation removes or transforms TypeScript syntax so a program can run. Type checking, meanwhile, examines whether the program follows its declared type relationships. A program that works correctly along the execution paths covered by tests may still contain type errors elsewhere.

The notable addition in Bun 1.4.3 is a built-in command that performs this second task.

bun check

The supplied report describes this command as accepting TypeScript files and checking their types. Before introducing it into an existing project, consult the release documentation for supported ways to run it, configuration handling, and command-line options.

This distinction matters when considering adoption. Teams already using Bun to run scripts may gain a convenient new way to check types. Teams using another runtime can also evaluate the type checker independently, provided it supports their project’s requirements. Changing the tool that checks source code does not require changing the runtime that executes the application.

The question to answer is therefore concrete: can this type checker validate your repository accurately while reducing the time and memory required?

The Speed Claims Deserve Attention, but the Comparison Conditions Need Clarification#

According to the report, Bun’s type checker is more than three times faster than TypeScript 7, which is implemented in Go.

That is a tougher comparison than outperforming the traditional JavaScript implementation of the type checker. TypeScript 7’s move to Go was itself intended to improve performance. Bun is claiming a further substantial reduction in runtime against that new baseline.

To get a sense of scale, consider a check that currently takes 90 seconds. At exactly three times the speed, the same work would finish in 30 seconds. This is an illustrative example, not a measured result from the Bun release.

Memory savings may be just as important. A type checker that uses half as much memory is easier to run alongside tests and builds on a CI runner. Further reductions could also help repositories that are currently approaching their runners’ memory limits.

However, the supplied material does not identify the benchmark hardware, the full set of projects tested, cache conditions, or measurement procedures. Nor does it establish whether the reported advantage applies equally to small applications, large monorepos, and projects with complex generic types.

Treat the release figures as a reason to try it. The results that matter to your workflow will come from your own repository.

What “100% Conformance” Actually Shows#

Performance is valuable only if the type checker actually catches the errors your team expects it to detect.

The supplied report describes two kinds of compatibility testing. First, Bun reportedly passed 100% of the TypeScript 7.0.2 conformance tests. Second, the team selected 72 open-source TypeScript files containing errors and compared the results from TypeScript and Bun, finding one discrepancy.

Passing a language implementation’s conformance test suite is meaningful evidence. It suggests broad agreement on the language behavior covered by those tests.

Still, there are limits to what the results establish. A test suite contains a finite set of cases. Passing all of them does not prove identical behavior across every combination of source files, compiler settings, package declarations, and dependency structures.

The 72-file comparison adds another kind of evidence: agreement on selected source-code examples outside the conformance suite. But the reported discrepancy needs investigation. The supplied text does not explain whether it involved a missed diagnostic, an extra diagnostic, or a difference in how an error was presented.

These have different consequences. A message change might require a small tooling adjustment. A missed error could undermine the reliability of a release gate.

The practical standard is agreement on the behavior your project relies on. That includes both rejecting invalid code and accepting valid code under the settings you actually use.

Faster Type Checking Can Improve Workflows#

The immediate benefit of a faster type checker is less waiting. Whether it delivers greater value depends on whether reducing the effort of running it changes developer behavior.

A check that finishes quickly is easier to run before committing. A slow check is more likely to be deferred to CI, with feedback arriving after the developer has moved on to another task.

Consider these two situations:

• After changing a shared API, a developer runs a full type check locally, fixes the affected callers, and then pushes.
• A developer pushes first, waits for CI, starts another task, and then returns to the change.

In the first workflow, the relevant code and the reasoning behind the decisions are still fresh in the developer’s mind. Faster type checking makes that workflow easier to maintain.

However, a type checker’s speedup does not translate directly into an equivalent reduction in total CI time. If type checking accounts for 90 seconds of a 10-minute pipeline, reducing it to 30 seconds saves one minute. Installing dependencies, running tests, and building still take the remaining time.

Parallel execution complicates matters further. If a longer-running test job determines when CI finishes, faster type checking may reduce resource usage without changing the final completion time.

Measure the type checker on its own first, then measure the pipeline.

A Four-Step Evaluation for an Existing Repository#

A useful trial should leave evidence that another engineer can verify. Keep its scope narrow enough to identify the cause if something goes wrong.

1. Record the Current Setup#

Record the TypeScript version, Bun version, operating system, and available CPU and memory. Also record the exact command currently used for type checking.

If your tools support it, measure elapsed time and peak memory usage. Run the check several times, noting whether each run used an existing cache.

Avoid comparing one tool without a cache against another with a cache. That can exaggerate differences unrelated to the type checkers themselves.

2. Compare Diagnostics#

Run both type checkers against the same commit and configuration.

Start with a revision that passes the existing check. Then, on a temporary branch, deliberately introduce representative errors, such as invalid arguments, incompatible assignments, unresolved imports, and incorrect return types.

These examples cannot prove complete compatibility. They can, however, confirm whether the type checker handles some of the problems your team expects it to detect.

Investigate every discrepancy. Record the affected files, settings, and a minimal reproduction. Do not dismiss a difference as harmless until you understand it.

3. Test Difficult Cases Specific to Your Repository#

Choose cases that reflect your actual codebase. A monorepo may rely heavily on package boundaries and project references. A frontend application may depend on generated type declarations and framework-specific tooling.

Pay particular attention to module resolution, path aliases, third-party type declaration files, and strictness settings. Check the documentation for support rather than assuming language conformance guarantees every integration detail.

If your existing TypeScript command also emits type declarations or performs other required build tasks, clarify how those responsibilities will be handled. A fast type-checking command does not automatically replace every use of the compiler.

4. Run a Temporary Comparison in CI#

For a defined period, run Bun’s type checker alongside the existing required check. Keep the current release gate in place while collecting execution times and diagnostics.

Along with deliberately introduced errors, examine changes made during normal development. Once the results support switching, document the measured benefits and remaining limitations, and make the change in a dedicated pull request.

This makes both adoption and any necessary rollback easier.

The Release Includes Other Performance Improvements#

Type checking is the headline feature, but the supplied release summary also lists faster JSON.parse, Node.js compatibility fixes, and reduced server CPU usage while idle.

The reported reduction in idle CPU usage is 67%. Treat this figure with the same care as the type-checker benchmarks. It is a result obtained under specific measurement conditions, not a guarantee that total production CPU usage will fall by the same amount.

For a busy service, request handling may account for most resource consumption. For a mostly idle service, background activity may account for a larger share. Test under conditions close to your own deployment environment.

This release also introduces Bun.FetchSession and includes numerous fixes. The supplied summary does not provide enough detail to assess this API’s behavior or recommend integrating it. Consult the release documentation before adopting it.

If your immediate goal is faster type checking, evaluate that change first. A focused trial makes the results easier to interpret.

Demonstrate That It Is Worth Switching#

Bun 1.4.3 makes an appealing proposition: substantially faster TypeScript type checking, reported reductions in memory usage, and strong conformance with TypeScript 7.0.2.

The remaining question is whether your repository can gain those benefits without introducing diagnostic differences that matter to your team.

Start by choosing one representative project. Pin Bun to version 1.4.3, run its type checker alongside your current TypeScript check, and record execution time, peak memory usage, and every discrepancy. Use that evidence to decide whether bun check should become a required check in your development workflow.

Source: https://www.publickey1.jp/blog/26/anthropicbuntypescript_73typescriptbun143.html