Deno 1.32

Deno 1.32: Enhanced Node.js Compatibility

🚨 Deno 1.32.0 contains a critical security issue. Please upgrade to 1.32.1.

Deno 1.32 has been tagged and released with the following new features and changes:

If you already have Deno installed, you can upgrade to 1.32 by running:

deno upgrade

If you are installing Deno for the first time:

# MacOS and Linux
curl -fsSL | sh

# Windows
iwr -useb | iex

Click here for more installation options.

Enhanced Node.js Compatibility

Deno continues to make significant strides in improving its compatibility with Node.js, offering a smoother overall developer experience. Key enhancements in this release include:

  • Limited package installation: Package installation is now limited to instances where code uses a bare specifier that matches an entry in the package.json file.
  • Lazy error surfacing: Dependency parsing errors in package.json are now surfaced in a lazy manner, minimizing disruptions.
  • Controlled auto-discovery: Package.json auto-discovery is disabled when the --no-config and --no-npm flags are set, providing greater control over the process.
  • New environment variable: A new DENO_NO_PACKAGE_JSON environment variable allows you to completely prevent Deno from resolving a package.json file within the environment.
  • Expanded crypto support: Support for the createCipheriv and createDecipheriv APIs in "node:crypto" has been added, expanding the range of available cryptographic functions.

These targeted usability improvements collectively contribute to a more seamless and efficient development experience when working with Deno and Node.js.

deno compile support for web workers and dynamic import

This release brings two highly requested update to deno compile. It is now possible to use dynamic imports and Web Worker API with binaries created using deno compile subcommand. Together this makes multi-threaded programs more easily buildable with deno compile.

If your dynamic import statements are statically analyzable (or in other words if you used string literals inside import()) the specifiers will be automatically included in the produced binaries:

// main.js
const dynamicModule = await import("./dynamic_module.js");

// dynamic_module.js
export function hello() {
  return "hello world!";
$ deno compile -o dynamic_import_example main.js
Compile file:///dev/main.js
Emit dynamic_import_example
$ ./dynamic_import_example
hello world!

For cases where the specifiers are not statically analyzable, you can use the new --include flag to specify additional files to include in the binary. This flag can be used multiple times.

// main.js
const worker1 = new Worker(import.meta.resolve("./worker1.js"), {
  type: "module",

worker1.postMessage("hello from main!");
worker1.onmessage = (e) => {
  console.log("main received",;

const worker2 = new Worker(import.meta.resolve("./worker2.js"), {
  type: "module",

worker2.postMessage("hello from main!");
worker2.onmessage = (e) => {
  console.log("main received",;
// worker1.js
self.onmessage = (e) => {
  console.log("worker1 received:",;
  self.postMessage("hello from worker1!");
// worker2.js
self.onmessage = (e) => {
  console.log("worker2 received:",;
  self.postMessage("hello from worker2!");
$ deno compile --include worker1.js --include worker2.js -o worker_example main.js
Compile file:///dev/main.js
Emit worker_example
$ ./worker_example
worker1 received: hello from main!
main received hello from worker1!
worker2 received: hello from main!
main received hello from worker2!

Thank you to Andreu Botella for contributing these features.

deno run files without an extension

It’s now possible to run files without an extension by specifying one via the --ext flag.

$ cat my_script
#!/usr/bin/env -S deno run --ext=js

$ ./my_script

Thank you to @Cre3per for contributing this feature.

Changes to Deno APIs is now defined on Windows. This is an additive change, but because of it the typings for field were changed from number | null to number.

Two new unstable APIs were added: Deno.DatagramConn.joinMulticastV4 and Deno.DatagramConn.joinMulticastV6. (Thank you to Sam Gwilym for contributing this.)

Changes to Web APIs

URLSearchParams.size() is now supported. (Thank you to Lino Le Van for contributing this feature.)

Unstable WebGPU API removed. Supporting WebGPU introduced a cost that made deno binaries bigger and slower to start up for all users, even if they didn’t use it. This release removes the unstable WebGPU API while implementations can be investigated that don’t increase startup time.

Changes to the standard library

Breaking changes to the module structure

The following 6 modules under std/encoding cateogry have been moved to the top level of the standard library in this release.

  • std/encoding/csv has been moved to std/csv
  • std/encoding/yaml has been moved to std/yaml
  • std/encoding/toml has been moved to std/toml
  • std/encoding/json has been moved to std/json
  • std/encoding/jsonc has been moved to std/jsonc
  • std/encoding/front_matter has been moved to std/front_matter

These changes were made to improve the consistency of the module/directory structure in the standard library. For example, csv module was exported from 2 different places formerly: std/encoding/csv.ts and std/encoding/csv/stream.ts. Now csv is exported from the single place std/csv/mod.ts (Also each single API is exported from each corresponding file. See the API document for details). We consider this structure more consistent. Please see the discussion issues (1 2) if you’re interested in more details.

Thanks Asher Gomez for working on this, and also thanks Tim Reichen and Lino Le Van for contributing to the discussion.

TypeScript 5.0

Deno v1.32 ships with the latest stable version of TypeScript. For more information on new features in TypeScript see TypeScript’s 5.0 blog post

Take note that ES decorators are not yet supported, but we will be working towards enabling them by default in a future version.

Performance improvements: Alongside the other performance benefits brought by TypeScript 5.0, Deno’s initial type-check became significantly faster when not type checking remote modules—without using the –all flag. This enhancement is particularly impactful in reducing type checking times on CI for most cases. The exact time savings depend on the number of remote modules in your dependencies, but we’ve observed more than 2x speedups in type checking (e.g., reducing times from 2200ms to 600ms).

V8 11.2

This release upgrades to the latest release of V8 (11.2, previously 11.0).

There are some new exciting JavaScript features available with this upgrade: