Deno 2.4 Brings Back deno bundle — And It's Better Than Ever

For a while, deno bundle felt like a deprecated footnote. Deno had removed it, pointing developers toward external build tools. But with Deno 2.4, bundle is back — and it shipped alongside a set of changes that make the entire JavaScript tooling story significantly more compelling for 2026 workflows.

If you've been on the fence about Deno for your Next.js-adjacent tooling, server-side scripts, or build pipelines, this release is worth a serious look.

deno bundle is Back

The reborn deno bundle now produces a single-file ES module output — no external bundler required. It handles TypeScript, JSX, npm specifiers, and remote imports out of the box. The key difference from v1: it generates proper ES modules rather than a Deno-specific bundle format, making the output portable.

# Bundle a TypeScript entry point to a single ESM file
deno bundle src/main.ts dist/bundle.js

# Bundle with a specific target for deployment
deno bundle --target=es2022 src/worker.ts dist/worker.js

This is useful for building Cloudflare Workers, edge function bundles, or any scenario where you need a single portable file. For teams that previously used esbuild just to bundle a few scripts, deno bundle can replace that dependency entirely.

Bytes and Text Imports

Deno 2.4 introduces native bytes: and text: import specifiers — a feature that eliminates a common fs.readFileSync pattern:

// Import a file as a Uint8Array at compile time
import wasmBytes from "bytes:./my_module.wasm";

// Import a file as a string
import htmlTemplate from "text:./templates/email.html";
import sqlQuery from "text:./queries/users.sql";

// Use them directly
const wasmModule = new WebAssembly.Module(wasmBytes);
console.log(htmlTemplate.includes("{{name}}")); // true

This pairs especially well with WASM modules and SQL query files. The import is resolved at startup — no async file reads, no path gymnastics, and the TypeScript types are correct out of the box (Uint8Array for bytes:, string for text:).

Stabilized Built-in OpenTelemetry

OpenTelemetry support graduated from unstable in 2.4. You can now instrument Deno apps with zero external SDK setup:

// No npm install required — Deno ships OTEL built-in
const tracer = Deno.openTelemetry.trace.getTracer("my-service");

async function handleRequest(req: Request): Promise<Response> {
  return tracer.startActiveSpan("handle-request", async (span) => {
    span.setAttribute("http.method", req.method);
    span.setAttribute("http.url", req.url);

    try {
      const result = await processRequest(req);
      span.setStatus({ code: 1 }); // OK
      return result;
    } catch (err) {
      span.recordException(err as Error);
      span.setStatus({ code: 2, message: "error" });
      throw err;
    } finally {
      span.end();
    }
  });
}

Connect it to any OTEL-compatible backend (Grafana, Datadog, Honeycomb) via the standard OTEL_EXPORTER_OTLP_ENDPOINT env var. No additional packages, no init boilerplate.

The --preload Flag

The new --preload flag lets you run a script before your main module — useful for polyfills, environment setup, or mock injection in tests:

deno run --preload ./setup-env.ts ./src/server.ts
deno test --preload ./test-setup.ts

Think of it as Deno's equivalent of Jest's setupFilesAfterEach or Node's --require flag, but cleaner and built into the runtime.

deno update for Dependency Management

Managing deno.json imports got easier with deno update — a command that checks all your dependencies for newer versions and updates the lockfile and config in one pass:

deno update        # Update all deps to latest compatible
deno update --dry-run  # Preview what would change

This brings Deno's DX closer to npm update / pnpm update without the node_modules overhead.

Should You Migrate from Node?

Deno 2.x has strong package.json and npm compatibility — most Node projects run without changes. The real wins for frontend engineers are:

• Zero config TypeScript — no ts-node, no tsconfig.json required for scripts
• Built-in formatter, linter, and test runner
• Faster cold starts than ts-node for CI scripts
• Native WASM, OTEL, and file imports without extra packages

Actionable Takeaways

• Use deno bundle to replace esbuild for simple single-file bundling scenarios (Cloudflare Workers, edge scripts)
• Replace fs.readFileSync patterns with bytes: and text: imports for compile-time asset inlining
• Adopt built-in OTEL now that it's stable — no SDK bloat, works with any OTEL backend
• Use --preload to simplify test setup and environment initialization
• Run deno update weekly in CI to stay current without manual lockfile management

Deno 2.4 isn't a revolution, but the compounding quality-of-life improvements are adding up. For TypeScript-heavy projects and edge deployments, it's increasingly hard to justify the Node + esbuild + ts-node stack over Deno's unified toolchain.