Deno 2.4 is here: What’s new and what to expect

Deno 2.4 speaks volumes about Deno’s direction. While it may be a minor version number on paper, the features packed inside represent a major push towards maturity, pragmatic developer experience, and production-readiness. This isn’t just a maintenance update; it’s a statement.

In the past, discussions around Deno often centered on its theoretical advantages, its robust security model, and its clean break from Node.js’s legacy. With version 2.4, the focus shifts to practical, real-world applications. Deno is aggressively enhancing its core tooling, smoothing out the developer workflow, and, most importantly, building robust bridges to the vast Node.js and npm ecosystem.

This article will break down the most impactful changes in Deno 2.4, moving beyond a simple changelog to explore what these updates mean for you as a developer. We’ll cover the triumphant return of a first-party bundler, new spec-aligned ways to handle assets, and the crucial steps being taken to make Deno a more compelling choice for any server-side JavaScript project.

Major tooling upgrades: Bundling and formatting

A runtime’s built-in tools can make or break the developer experience. Deno 2.4 delivers significant upgrades to its toolchain, most notably by bringing back a powerful, fan-favorite feature.

The return of deno bundle

For long-time Deno users, the return of the deno bundle subcommand is huge news. After being deprecated because of the sheer complexity of the task, it’s now back and built to last, leveraging the battle-tested power of esbuild under the hood.

This isn’t just a simple concatenation tool. The new deno bundle is a full-featured bundler that can transpile TypeScript, handle dependencies from npm and JSR, and create a single, tree-shaken, and minified JavaScript file ready for deployment. This brings a core workflow directly into the runtime, reducing the need for external build tools.

Creating a production-ready browser bundle is now a one-line command:

# Bundle with minification for the browser
deno bundle --platform browser --minify main.ts -o app.js

With plans for a programmatic API and a plugin system on the horizon, deno bundle is positioned to be an even more integral part of the Deno ecosystem.

Expanded deno fmt capabilities

On the formatting front, deno fmt gets a nice quality-of-life improvement. It now automatically discovers and formats .xml and .svg files, extending its “one command to format everything” promise beyond just code. It’s a small change that further streamlines the process of keeping your entire project clean and consistent.

A more mature developer experience (DX)

Beyond the headline features, Deno 2.4 is filled with thoughtful improvements that remove friction from the day-to-day development cycle. These updates show a focus on making common tasks simpler, faster, and more intuitive.

Simplified dependency management with deno update

Keeping dependencies current is a routine task that should be painless. Deno 2.4 introduces the deno update command, a more intuitive alias for the older deno outdated --update. It does exactly what you’d expect: checks your deno.json or package.json file and updates your JSR and npm dependencies to the latest compatible versions.

To update all packages to their latest versions, ignoring semver constraints, the command is simple:

deno update --latest

It’s a small change, but it makes the dependency management workflow feel more standard and streamlined.

Granular code coverage with deno run --coverage

Previously, deno test --coverage worked well for most cases but had a blind spot: it couldn’t track the coverage of subprocesses spawned during a test run. This could lead to inaccurate reports in complex integration or end-to-end testing scenarios.

Deno 2.4 addresses this by adding the --coverage flag to the deno run command. Now, you can collect coverage information on any script execution, ensuring that even code running in child processes is included in your final report. This gives you a far more accurate and complete picture of your project’s test coverage.

Running bare specifiers with deno run

This is another quality-of-life improvement that removes unnecessary keystrokes. You can now execute scripts using the bare specifiers you’ve defined as aliases in your deno.json import map.

For example, with this deno.json:

{
  "imports": {
    "cowsay": "npm:cowsay"
  }
}

You can now run the package directly without providing a full path or file name:

# This now works directly in Deno 2.4
deno run -ER cowsay "DX is getting better"

This makes running command-line tools and project-specific entry points feel much more natural.

Advanced environment control with the --preload flag

For framework authors and developers building custom platforms on top of Deno, the new --preload flag is a powerful addition. It allows you to specify a module that will be executed before your main application script runs.

This is perfect for advanced use cases like modifying globals, setting up polyfills, or initializing services before the user’s code is loaded. It provides a clean hook for preparing the runtime environment without altering the application code itself.

Modern JavaScript: Importing raw assets

Dealing with non-JavaScript assets like text files, icons, or other binary data has often involved runtime file system calls, decoupling the asset from your module graph. Deno 2.4 introduces a powerful, spec-aligned way to handle this by allowing you to import these assets directly.

Using import attributes (with { type: "..." }), you can now pull raw text or byte data into your application just like any other module. This approach treats your assets as first-class citizens of the module graph:

// Import the content of a text file as a string
import message from "./hello.txt" with { type: "text" };

// Import the content of a file as a Uint8Array
import iconBytes from "./icon.png" with { type: "bytes" };

console.log(message); // "Hello, Deno!"
console.log(iconBytes); // Uint8Array(...)

The true power of this feature is unlocked when combined with Deno’s tooling.

When you use deno bundle, these imported assets are inlined directly into your final JavaScript bundle. There’s no need to manage a separate assets folder or configure complex loaders.

Even better, when using deno compile, the assets are embedded directly into the final, standalone executable. This means you can create a single, truly portable binary that contains everything it needs to run, including configuration files, templates, or small databases.

Bridging the gap: Deepening Node.js compatibility

For many developers, the biggest question around Deno has been compatibility with the existing npm ecosystem. Deno 2.4 delivers some of the most significant compatibility updates yet, making it easier than ever to run Node.js projects and leverage npm packages.

The DENO_COMPAT=1 superpower

Previously, running an existing Node.js project in Deno often required a long list of command-line flags to enable various compatibility layers. Deno 2.4 streamlines this dramatically with a new environment variable: DENO_COMPAT=1.

Think of this as a master switch for Node.js compatibility. Setting it automatically enables a collection of flags like --unstable-node-globals and --unstable-sloppy-imports, saving you from having to remember and type them all:

# Before: A long, unwieldy list of flags
deno --unstable-detect-cjs --unstable-node-globals --unstable-sloppy-imports app.js

# After: Clean, simple, and portable
DENO_COMPAT=1 deno app.js

This is a huge win for developer experience, making Deno a more accessible drop-in runtime for Node.js projects.

Stabilized Node.js globals

Another common point of friction has been the availability of Node.js-specific globals. In previous versions, variables like Buffer, global, and setImmediate were only available within npm packages or when explicitly enabled with a flag.

In Deno 2.4, these globals are now available everywhere by default. This change removes a layer of complexity and potential errors, making the Deno environment feel more familiar and behave more predictably for developers coming from Node.js.

Support for conditional package.json exports

Modern npm packages are increasingly using conditional exports to provide different versions of their code for different environments (e.g., Node.js vs. browser). A key example is the react-server condition used by libraries to expose specific code for React Server Components.

Deno 2.4 now supports these conditions, allowing it to correctly resolve and use these sophisticated packages. This ensures Deno can keep pace with the cutting edge of the JavaScript ecosystem and work seamlessly with modern frameworks like Next.js, SvelteKit, and others that rely on this mechanism.

Production-ready features: Observability and security

For any application to be considered production-ready, it needs robust security and observability. Deno 2.4 delivers key updates in both areas, making it a more dependable choice for deploying critical services.

OpenTelemetry is now stable

Deno’s built-in support for OpenTelemetry (OTel), a standard for collecting traces, metrics, and logs, is now stable. This means you no longer need the --unstable-otel flag to use it.

By simply setting the OTEL_DENO=1 environment variable, you get zero-config, auto-instrumented observability for your applications. This automatically associates logs with HTTP requests and provides deep traces into your code’s behavior, which is invaluable for debugging and monitoring performance in a live production environment.

More flexible permission controls

Deno’s signature security model continues to evolve, becoming both more powerful and more ergonomic.

The --allow-net flag is now more flexible, supporting subdomain wildcards (e.g., .example.com) and CIDR ranges for IP addresses. This makes it much easier to manage network permissions for applications that need to communicate with a wide but well-defined range of hosts.

Additionally, this release introduces a new --deny-import flag. This complements --allow-import by letting you explicitly block code imports from certain hosts, giving you another layer of control for locking down your application’s dependency supply chain.

Conclusion

Deno 2.4 is far more than a minor update; it’s a clear signal of the runtime’s direction. By focusing on practical, high-impact features, the Deno team is building a platform that is not only innovative but also deeply pragmatic.

From the return of a powerful, first-party bundler to the massive strides in Node.js compatibility, this release is all about lowering barriers and removing friction for developers. The stabilization of production-critical features like OpenTelemetry and the continued refinement of the security model show a commitment to enterprise-readiness.

Whether you’re a long-time Deno user or a Node.js developer looking for a modern alternative, Deno 2.4 makes a compelling case. It’s a faster, more convenient, and more powerful tool, solidifying its position as a top-tier runtime in the server-side JavaScript landscape.