Deno 2: Goodbye deno bundle, Hello Modern Bundling!

Deno 2 has been officially released, marking a significant milestone in the evolution of this modern runtime for JavaScript, TypeScript, and WebAssembly. One of the key updates introduced in Deno 2 is the removal of the deno bundle feature, which has been a topic of interest and discussion among developers in the Deno community.

Why deno bundle was removed?

The deno bundle command was once the hero of developers looking to create single-file JavaScript bundles from their modular codebases. It was like a magical shrink-wrap machine for your project, combining all the scattered modules into one tidy, self-contained file. Need to share your project or deploy it somewhere that modular imports were still a far-off dream? No problem—deno bundle had your back. It was the duct tape of bundling solutions: simple, reliable, and maybe not the prettiest, but it got the job done.

But alas, as the JavaScript ecosystem evolved, our trusty bundle buddy found itself with fewer places to shine. The rise of native ES Modules and the unstoppable march of modern build tools like esbuild and Rollup meant that deno bundle started feeling a bit like the office printer—useful, sure, but only when you absolutely had to deal with it.

Enter Deno 2, and the development team’s tough-love decision to let deno bundle go. It wasn’t you, deno bundle; it was all of us. Developers didn’t need you as much anymore, and in true Marie Kondo fashion, the Deno team decided it was time to thank you for your service and move on to things that “spark joy.” By removing deno bundle, they’ve streamlined the runtime, keeping it lean, mean, and focused on the modern needs of developers.

For those still clinging to their deno bundle days, fret not! There are now smarter and shinier alternatives. Tools like esbuild are like the cool kids at the bundling party—fast, efficient, and great at optimizing your code. Or, if you’re looking for something closer to home, the deno_emit API is here to help. Think of it as the deno bundle younger, tech-savvy sibling who’s better at keeping up with today’s trends.

So let me show you how we can use esbuild to mimic the now-departed deno bundle feature. With a few tweaks and commands, esbuild can step in and handle bundling duties like a pro, giving you the same outcome: a single, ready-to-use JavaScript file that combines all your modules seamlessly.”

Example of using esbuild to Mimic the Removed deno bundle

first let’s create the bundle.ts file

import { denoPlugins } from "jsr:@luca/esbuild-deno-loader@0.9";
import * as esbuild from "https://deno.land/x/esbuild@v0.20.1/mod.js";


const config: Record<string,unknown>= {}
config.plugins     = [...denoPlugins()];
config.entryPoints = ['main.ts'];        // The script to bundle 
config.outdir      = 'out';              // The outpt diretcory of the generared file
config.bundle      = true;
config.platform    = 'browser';
config.format      = 'esm';
config.target      = 'esnext';
config.minify      = true;
config.sourcemap   = true;
config.treeShaking = true;

esbuild.build(config);
await esbuild.stop();

This script generates a single JavaScript file that consolidates all the necessary modules from your project into one cohesive bundle. The resulting file is fully self-contained and ready to be directly embedded into an HTML document.

This approach simplifies deployment by eliminating the need to manage multiple module files separately, ensuring that all dependencies are included in a single script. It is particularly useful for scenarios where modular imports are not supported or where simplicity and portability are key requirements, such as embedding scripts in static web pages or sharing projects with minimal setup requirements.

Now, to generate the the one cohesive bundle, you can invoke the following command:

deno run --allow-run --allow-net --allow-env --allow-read --allow-write bundle.ts

And voilà! Your script is now ready to rock and roll.