Deno 2.4: deno bundle Is Back and Built on esbuild

Deno killed deno bundle in 2021 because it was too hard to do right. In 2.4, it’s back — and this time it runs on esbuild. That’s not a minor DX tweak. It’s Deno admitting it got something wrong, delegating to a better tool, and shipping the result. For a project that has spent years making principled stands, that kind of pragmatism is worth noticing.

deno bundle Returns, Powered by esbuild

The original deno bundle was cut from Deno 2.0. The deprecation issue from 2021 was refreshingly blunt: “JavaScript bundling is an incredibly complex problem, and we did not believe we could build deno bundle properly.” When npm and Node module support arrived, the internal bundler couldn’t keep up.

Now, rather than rebuilding from scratch, Deno 2.4 delegates to esbuild under the hood. The result is a bundler that handles TypeScript transpilation, npm and JSR dependencies, tree shaking, and minification — and targets both browser and server platforms.

# Server-side bundle with minification
deno bundle --minify main.ts

# Browser target with output file
deno bundle --platform browser --output dist/bundle.js app.jsx

# With external source maps
deno bundle --platform browser --output dist/bundle.js --sourcemap=external app.jsx

There’s also a new raw asset import syntax that bundles cleanly with deno bundle and embeds into standalone binaries via deno compile:

import config from "./config.txt" with { type: "text" };
import logo from "./logo.png" with { type: "bytes" };

That combination — bundle + compile + raw imports — gives Deno a coherent story for shipping self-contained artifacts without reaching for any external tools. The Deno team calls this permanent: “it is here to stay.” A programmatic API and plugin support are planned for future releases.

The Other Three Features Worth Knowing

OpenTelemetry Is Now Stable

Built-in OpenTelemetry moved from unstable to stable in 2.4. Drop the --unstable-otel flag. Just set one environment variable:

OTEL_DENO=1 deno --allow-net server.ts

Deno auto-instruments HTTP requests served via Deno.serve and outgoing fetch calls, exporting to any OTLP-compatible backend — Grafana, Datadog, Honeycomb, whatever you already run. No SDK, no manual span creation, no extra packages. Production observability with one env var is a legitimate differentiator, and shipping it as stable removes the last “but it’s experimental” objection.

deno update Command

deno update is a cleaner alias for deno outdated --update. It updates npm and JSR dependencies in deno.json or package.json:

deno update              # update all to latest semver-compatible
deno update --latest     # force latest regardless of semver
deno update "@std/*"     # update only std library packages
deno update --recursive  # update in all subdirectories

Small change, big discoverability win. Developers coming from npm or Bun expect a runtime-native update command. Now Deno has one.

–preload Flag

Execute code before the main module across deno run, deno test, and deno bench:

deno --preload setup.ts main.ts

Node.js developers know this as --require. It’s useful for injecting globals, setting up feature flags, loading environment configuration, or bootstrapping custom instrumentation before your code runs.

Where deno bundle Fits (and Where It Doesn’t)

Be clear-eyed about this: deno bundle is not replacing Vite. If you’re building a frontend app with hot module replacement, a plugin ecosystem, and a dev server, stay on Vite. The tooling gap isn’t there.

Where deno bundle belongs:

• Deno-native CLI tools and servers — single-file output without a build config file
• Deno Deploy functions — bundle before pushing if you need npm deps inlined
• TypeScript CLIs — TypeScript in, minified JS out, no tsconfig to wrangle
• Projects already on Deno — eliminates the last reason to reach for esbuild directly

What it doesn’t displace: Vite for frontend apps, Webpack for legacy complexity, standalone esbuild for raw speed in library pipelines. The dependency management improvements in this release reinforce the same positioning: Deno is getting better at being a complete toolchain for Deno projects, not a universal replacement for the npm ecosystem.

The Verdict

Deno 2.4 is a “settle down and ship” release. It doesn’t rewrite the rules. It takes things that were missing or unstable — a bundler, production observability, a dependency updater — and makes them production-grade. The esbuild delegation for deno bundle is the right call, and the team’s willingness to say “we couldn’t do this well ourselves” is a green flag, not a red one. If you’ve been keeping Deno at arm’s length while waiting for it to mature, this is a reasonable checkpoint to reconsider. Check the Deno 2.4 release notes and upgrade with deno upgrade.