Programming should be simple. That’s why we made Deno a zero-config, batteries-included JavaScript runtime with native TypeScript support, enabling immediate productivity.

In version 1.43, we have enhanced the performance of Deno in IDEs by reducing auto-completion times from 6-8 seconds to under one second in large codebases and significantly decreasing memory usage. We have also achieved more complete npm compatibility by reworking our node:vm and node:worker_threads implementations, widely used in JavaScript CLI tools like test runners.

To upgrade to Deno 1.43, run the following in your terminal:

If Deno is not yet installed, learn how to install it here.

What’s New in Deno 1.43

• Speeding up Deno’s Language Server
• Node.js and npm compatibility
• Using npm commands in deno.json tasks
• Faster ES and CommonJS module loading
• JSX precompile improvements
• jsxImportSourceTypes
• Introducing deno serve subcommand
• Deno.serve() updates
  • Response completion
  • Simpler access to the server address
• URL.parse() Web API
• The Standard Library is moving closer to stabilization
• Android builds for rusty_v8
• V8 12.4
• Try out Deno 2 features with DENO_FUTURE=1
• Acknowledgments

Speeding up Deno’s Language Server

A few Deno users reached out to tell us that our Language Server struggled with bigger projects that had a large number of files. The Language Server (commonly referred to as Deno LSP) provides autocompletion, among other things, in your editor. When they shared what the editor experience was like in those projects, we realized that we could improve the responsiveness and memory consumption substantially.

This cycle, we spent most of our time reworking many aspects of the LSP, making it faster and more efficient. In larger projects, where auto-completion previously took about 6-8 seconds, we have reduced it to under one second. Similarly, memory consumption has improved significantly, allowing projects that previously caused out-of-memory errors in our LSP to operate without issue.

Before:

After:

Node.js and npm compatibility

This release includes many key improvements around the node:worker_threads and node:vm modules. Both modules are used frequently in test runners, like Jest and Vitest, as well as tools like Docusaurus. In fact, we’re now running Docusarus to power some of our documentation sites with Deno.

• Implement process.kill in Rust to avoid run permission prompt. This makes ora, a popular CLI spinner library, work in Deno.
• Add missing http.maxHeaderSize value to make undici work.
• fs.cpSync: Always ensure the parent directory exists for SolidStart.
• Support env option in node:worker_threads. This enables calling sveltekit build to complete successfully.
• Correctly send ALPN on node TLS connections which confused upstream servers
• Fix AsyncResource borrow panic which broke ng serve and vitest.
• Fix Promise rejection in node:vm contexts which is used in docusaurus build.
• Implement MessagePort.unref() used for @angular/cli serve.
• Fix out of order writes of fs.createWriteStream which occured in koa-body.
• Ensure hostname in node:http is a valid IPv4 address which fixes docusaurus serve.
• Add module to builtinsModule for docusaurus build.
• Fix node:worker_thread worker exiting prematurely.
• Polyfill node:domain module to fix configuration discovery in web-ext.
• Fix transferred MessagePort not having an .on handler which is needed for piscina used in Angular.
• Fix parseArgs from node:util not supporting the default option.
• Add missing fs.readv, fs.readvSync functions.

Other frameworks, like SolidStart, are inching closer to full support as well. We’ve got the basics down, but some work remains to be done to fully support their https server and auth-js:

SolidStart and other framework compatibility improvements are being done behind the new DENO_FUTURE=1 environment variable, which you can read about below.

Another area we tackled was improvements to AsyncResource which is necessary to make vitest work as it depends on the tinypool package, which in turn makes heavy use of Node’s AsyncResource under the hood.

And of course, we’re working on supporting Next.js too. We got the initialization wizard fully working thanks to some improvements around our handling of the layout in the node_modules directory.

~/my-app $ DENO_FUTURE=1 deno task dev
Task dev next dev
   ▲ Next.js 14.1.3
   - Local:        http://localhost:3000

 ✓ Ready in 2.2s
 ○ Compiling / ...
 ✓ Compiled / in 5.5s (511 modules)
 ✓ Compiled in 381ms (241 modules)

Running Next.js currently requires enabling some unstable flags in Deno, and we’re well underway in the process of stabilizing them.

Using npm commands in deno.json tasks

Executable npm commands like vite, typically managed through package.json scripts, can now be directly referenced in tasks defined in deno.json as well.

// deno.json
{
  "tasks": {
    "start": "vite"
  }
}

Faster ES and CommonJS module loading

This release adds support for V8 code caching (also known as bytecode caching), which can significantly improve the time your application spends on parsing and compiling JavaScript modules. The compiled bytecode is automatically cached on local disk when a module is loaded for the first time, and then reused on subsequent loads.

In our testing, we’ve observed startup time improvements between 5% and 240% depending on the application.

JSX precompile improvements

Since version v1.38 Deno comes out of the box with a precompile JSX transform that is optimized for server side rendering performance. In certain scenarios a framework might want to prevent an element to be precompiled to allow passing additional properties to it. Our transform learned a new trick to make this possible with the jsxPrecompileSkipElements compiler option.

// deno.json
{
  "compilerOptions": {
    "jsx": "precompile",
    "jsxImportSource": "preact",
    // Don't precompile <a>, <body>, and <img> elements
    "jsxPrecompileSkipElements": ["a", "body", "img"]
  }
}

You can pass an array of elements to that option to exempt them from being precompiled.

const a = <a href="#">click me</a>;


const $$_tpl_1 = ['<a href="#">click me</a>'];
const a = jsxTemplate($$_tpl_1);


const a = jsx("a", {
  href: "#",
  children: "click me",
});

jsxImportSourceTypes

A new jsxImportSourceTypes pragma and compiler option allows specifying the types for the automatic JSX transform. This is useful to use with libraries that don’t provide their types.

export function Hello() {
  return <div>Hello!</div>;
}

Alternatively, this can instead be specified in a deno.json file:

{
  "compilerOptions": {
    "jsx": "react-jsx",
    "jsxImportSource": "npm:react@^18.3",
    "jsxImportSourceTypes": "npm:@types/react@^18.3"
  }
}

Introducing deno serve subcommand

In this release we’ve added deno serve subcommand, that allows you to write servers in a declarative way:

export default {
  fetch(request) {
    return new Response("Hello world");
  },
};

$ deno serve server.ts
deno serve: Listening on http://localhost:8000/
$ curl http://localhost:8000/
Hello world

Notice that you don’t have to pass any permission flags - deno serve applies appropriate --allow-net permission automatically that allows it to listen for incoming HTTP connections. Still, you can pass extra permission flags as needed.

Additionally, you can use --host and --port flag to configure which interface the server binds to:

$ deno serve --host 0.0.0.0 --port 3000 server.ts
deno serve: Listening on http://0.0.0.0:3000/
$ curl http://0.0.0.0:3000/
Hello world

Our plan is to introduce automatic load-balancing in the future, that will run the server on multiple CPU cores allowing for better utilization of your system resources.

Deno.serve() updates

Response completion

You can now get information if the response was sent successfuly or there was a failure using the Deno.ServeHandlerInfo.completed promise:

Deno.serve((req, info) => {
  info.completed.then(() => {
    console.log("Response sent successfuly!");
  }).catch(() => {
    console.error("Failed sending the response.");
  });
  return new Response("Hello world");
});

Additionally, the AbortSignal attached to the Request argument will always be aborted when a transaction finishes - whether by client closing the connection or server sending the response.

Deno.serve((req, info) => {
  req.signal.addEventListener("abort", () => {
    console.log("Response finished");
  });
  return new Response("Hello world");
});

Simpler access to the server address

We added a minor quality of life improvement that makes it easier to get the server address from Deno.serve. Previously, you had to write something like this:

let listenPort: number | null = null;

Deno.serve(
  {
    onListen: ({ port }) => (listenPort = port),
  },
  () => new Response("hello world"),
);

By adding a new addr property directly on the server instance this becomes much simpler:

const server = Deno.serve(() => new Response("hello world"));
const port = server.addr.port;

URL.parse() Web API

The new Web API URL.parse() provides a simpler control flow when you need to parse URLs.

Before this addition, the way to parse was to construct a new URL instance. The crux is that new URL(input, base) throws an error if the url you’re parsing is not valid; while URL.parse(input, base) will just return null for invalid urls.

So if you’re parsing a URL and need to provide a fallback in case parsing fails, you can replace this code:

let url;
try {
  url = new URL(userProvidedValue, "http://deno.land");
} catch {
  url = new URL("http://deno.land");
}

With this code:

const url = URL.parse(userProvidedValue, "http://deno.land") ??
  new URL("https://deno.land");

Thank you to Kenta Moriuchi for implementing this API.

The Standard Library is moving closer to stabilization

The Deno Standard Library (deno_std) offers a set of high quality packages that are audited by the core team and guaranteed to work with Deno.

We’ll have a full blog post on this in the coming days, but starting in Deno 1.43, the Standard Library will be published exclusively to JSR under the @std scope. Existing versions of the Standard Library will continue to live at https://deno.land/std. This move, alongside Deno’s new workspaces functionality, is part of the changes coming in Deno 2. For more details, check out the Standard Library’s roadmap for stabilization.

Android builds for rusty_v8

Whilst we don’t provide Android builds ourselves, we received a great patch that makes it easier to build rusty_v8 for Android.

Thanks to @Taknok for contributing this.

V8 12.4

Deno 1.43 ships with V8 12.4, which adds support for a new TypedArray kind: Float16Array.

This API proves useful in several GPU related applications.

Try out Deno 2 features with DENO_FUTURE=1

In anticipation of the upcoming Deno 2 release, we’ve put breaking changes for Deno 2 behind the DENO_FUTURE=1 environment variable. Enabling it allows you to test compatibility of your project with Deno 2.

This includes the following:

• Override BYONM with nodeModulesDir setting
• Remove deprecated Deno.* APIs in Web Workers
• Enable BYONM by default when package.json is present
• Remove Deno.ConnectTlsOptions.certFile
• Remove Deno.ConnectTlsOptions.certChain
• Remove Deno.ConnectTlsOptions.privateKey
• Remove Deno.ListenTlsOptions.keyFile
• Remove Deno.ListenTlsOptions.certFile
• Remove Deno.customInspect
• Remove Deno.Conn.prototype.rid
• Remove Deno.TlsConn.prototype.rid
• Remove Deno.Listener.prototype.rid
• Remove Deno.TlsListener.prototype.rid
• Remove Deno.UnixConn.prototype.rid
• Remove Deno.FsWatcher.prototype.rid
• Make Deno.FsFile constructor illegal

Acknowledgments

We couldn’t build Deno without the help of our community! Whether by answering questions in our community Discord server or reporting bugs, we are incredibly grateful for your support. In particular, we’d like to thank the following people for their contributions to Deno 1.43: Alex Yang, Carlos Precioso, JOTSR, Javier Viola, Kenta Moriuchi, MAKS11060, nokazn, welfuture, youngwendy, 林炳权, chirsz-ever.

Would you like to join the ranks of Deno contributors? Check out our contribution docs here, and we’ll see you on the list next time.

Believe it or not, the changes listed above still don’t tell you everything that got better in 1.43. You can view the full list of pull requests merged in Deno 1.43 on GitHub here.

Thank you for catching up with our 1.43 release, and we hope you love building with Deno!

🍋 Fresh 2.0 is right around the corner.

Our next major Fresh release will be simpler with a more composable, routing API. Read more here.