Eliminating the Build Step: Direct TypeScript Execution with Bun

The Friction of the 'Compile-Run' Cycle

Modern TypeScript development often feels like fighting the toolchain. To run a simple script, you typically need a transpiler (like tsc or esbuild), a loader (like ts-node), or a full build pipeline that converts .ts files into .js before the runtime can touch them. This creates a cognitive gap between writing code and seeing it execute.

Bun removes this gap by integrating a native transpiler directly into the runtime. Instead of treating TypeScript as a language that must be converted to JavaScript, Bun treats it as a first-class citizen that can be executed immediately. The takeaway is simple: you can stop managing tsconfig.json purely for execution and start running your source files directly.

How Bun Handles TypeScript

Bun uses a built-in transpiler to strip TypeScript type annotations on the fly. It does not perform type checking during execution. This is a critical engineering decision: by ignoring the types and focusing only on the valid JavaScript syntax underneath, Bun achieves near-instant startup times.

This approach transforms the development workflow. You no longer need a dist folder or a watch script that triggers a rebuild every time you save a file. You simply point the runtime at your .ts file, and it handles the rest using the JavaScriptCore engine.

Integrating the Toolchain

The removal of the build step extends beyond just execution. Bun replaces several fragmented tools with a single binary:

• Package Management: bun install uses a binary lockfile, which significantly reduces the time spent in node_modules resolution compared to npm.
• Testing: bun test provides a Jest-compatible runner. Because it understands TypeScript natively, you don't need to configure ts-jest or babel-jest to run your test suites.
• Serving: Bun.serve() provides a high-performance HTTP server API that avoids the overhead of the legacy Node.js http module.

Worked Example: A Zero-Config TypeScript Server

To see this in action, you can create a TypeScript server without a single build configuration file. This example assumes Bun is installed on your system.

// server.ts
const server = Bun.serve({\n  port: 3000,\n  fetch(request) {\n    const url = new URL(request.url);\n    if (url.pathname === "/") {\n      return new Response("Welcome to Bun!");\n    }\n    return new Response("Not Found", { status: 404 });\n  },\n});

console.log(`Listening on ${server.port}...`);

Execution: Run the following command in your terminal (requires Bun installed):

bun run server.ts

Verification: Open your browser to http://localhost:3000. You will see "Welcome to Bun!" without ever having run a compiler.

The Trade-off: Type Safety vs. Speed

The most significant limitation of Bun's approach is the absence of runtime type checking. Because Bun strips types to maximize speed, it will happily execute code that contains TypeScript errors. If you have a type mismatch, Bun will not warn you; it will simply run the code as JavaScript, which may lead to runtime crashes.

To maintain type safety, you must still use the TypeScript compiler (tsc) as a static analysis tool. The recommended pattern is to run tsc --noEmit in your CI/CD pipeline or as a background process in your IDE to catch errors, while using bun run for actual execution.

Practical Verification

To verify if Bun is the right fit for your project's execution flow, try these three checks:

1. Execution: Create a .ts file with a simple console.log and run bun run file.ts. If it prints without a tsc step, the transpiler is working.
2. Installation: Run bun install in a project with a large package.json and compare the speed to npm install.
3. Testing: Create a .test.ts file using expect() and test(), then run bun test to verify the native runner's compatibility.