Eliminating the TypeScript Compile-Wait Loop with Bun

The friction of the build step

In a traditional TypeScript environment, the path from writing a line of code to seeing it execute involves a middleman: the compiler. Whether you use tsc, ts-node, or a complex Webpack/esbuild pipeline, there is a measurable delay. This "compile-wait loop" breaks developer flow, especially when tweaking small logic changes or debugging API responses.

Direct execution via integrated transpilation

Bun solves this by integrating a transpiler based on SWC (Speedy Web Compiler) directly into the runtime. Instead of requiring a separate build phase that outputs JavaScript files to a /dist folder, Bun handles the transformation in memory.

When you execute a .ts file, Bun strips the type annotations and transforms the syntax into JavaScript that the engine can execute immediately. This process is nearly instantaneous for most files, allowing TypeScript to feel as lightweight as a scripting language while maintaining the developer experience of a typed system.

Worked Example: Instant HTTP Server

To see this in action, you can deploy a functional server without a single configuration file or build command.

1. Install Bun: Run the following in your terminal (standard user permissions required):
   

   curl -fsSL https://bun.sh/install | bash

2. Verify Installation: Check that your version is 0.1.0 or higher:
   

   bun -v

3. Create the Server: Create a file named server.ts with this content:

   import { serve } from "bun";
   
   const port = 3000;
   console.log(`Listening on http://localhost:${port}`);
   
   serve({
     port,
     fetch(req) {
       return new Response("Hello from Bun + TypeScript");
     }
   });
   

4. Execute: Run the file directly from your project directory:
   

   bun run server.ts

Verification: Navigate to http://localhost:3000. You will see the response immediately. If you check your project folder, you will notice that no .js files were generated; the execution happened entirely in memory.

Integrating with tsconfig.json

Bun does not ignore your project settings. If you have a tsconfig.json, Bun reads it to handle module resolution and aliases. For example, adding the following configuration ensures Bun handles JSX correctly if you expand your project:

{
  "compilerOptions": {
    "target": "ES2018",
    "jsx": "react"
  }
}

Trade-offs and Technical Limits

While the speed is significant, Bun's approach is transpilation, not full type-checking. This means Bun removes types to run the code but does not alert you to type errors during execution. You still need tsc --noEmit in your CI/CD pipeline or IDE to catch type mismatches.

There are also specific architectural limitations:

• Advanced TSC Features: Bun may not support every niche tsc flag. Features like project references or custom transformers may still require the official TypeScript compiler.
• Cold Starts in Monorepos: In massive codebases, Bun's one-shot transpilation can occasionally be slower than tsc's incremental watch mode, which only updates changed files.
• Version Variance: While stable, specific behaviors (like the --tsc flag for forced compiler use) were introduced in v0.6.0; ensure your runtime is updated to match the desired behavior.

Practical Implementation Path

To integrate this into your workflow without risking production stability, follow this tiered approach:

• Local Development: Use bun run index.ts for rapid iteration and testing.
• Type Validation: Run tsc --noEmit as a background process or pre-commit hook to ensure type safety.
• Production: Continue using your established build pipeline if you rely on advanced custom transformers, or migrate to Bun if your project fits within its supported transpilation set.