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

• Cache Web API
• WebCrypto Secure Curves
• --allow-sys permission flag
• Improvements to npm support
• Node.js compatibility improvements
• Changes to Deno APIs
• Improvements to Deno.serve() API
• Performance improvements
• Improved module download UI
• Developer experience improvements
• TypeScript 4.8

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

If you are installing Deno for the first time:

curl -fsSL https://deno.land/x/install/install.sh | sh


iwr https://deno.land/x/install/install.ps1 -useb | iex

Click here for more installation options.

Cache Web API

We added support for the Cache API in this release.

The API allows you to cache Request/Response objects. This is helpful when you dynamically generate responses. It allows you to cache a response for a GET request and serve response from the cache for similar requests.

Here’s a small example that generates response based on name query:

import { serve } from "https://deno.land/std@0.158.0/http/server.ts";


const CACHE = await caches.open("v1");

serve(async (req: Request) => {
  
  const res = await CACHE.match(req);
  if (res) {
    res.headers.set("x-cache-hit", "true");
    return res;
  }

  const { searchParams } = new URL(req.url);
  const name = searchParams.get("name");
  const response = new Response(`Hello ${name}!`);
  
  await CACHE.put(req, response.clone());
  return response;
});

The cache is persisted to the file system. So restarting Deno will not flush the cache.

The following APIs are implemented:

• CacheStorage::open()
• CacheStorage::has()
• CacheStorage::delete()
• Cache::match()
• Cache::put()
• Cache::delete()

Few things that are different compared to browsers:

1. You cannot pass relative paths to the APIs. The request can be an instance of Request or URL or a url string.
2. match() & delete() don’t support query options yet.

WebCrypto Secure Curves

The WebCrypto Secure Curves specification adds support for Curve25519 and Curve448 to the WebCrypto API.

Deno v1.26 implements the CFRG curves Ed25519 and X25519.

const key = await crypto.subtle.generateKey("X25519", true, ["deriveKey"]);

We plan to add support for Ed448 and X448 in future releases.

--allow-sys permission flag

Deno has a number of APIs that provide information about user’s operating system, eg. Deno.osRelease(), Deno.systemMemoryInfo().

Previously access to these APIs required the --allow-env flag, which was unfortunate as it meant you had to grant permission to read all environment variables in order to access information about the OS.

Deno v1.26 introduces a new --allow-sys permission flag, that guards access to these APIs, which means you no longer need to also make your environment variables available.

The following APIs require the --allow-sys flag:

• Deno.hostname()
• Deno.networkInterfaces()
• Deno.loadavg()
• Deno.getUid()
• Deno.getGid()
• Deno.osRelease()
• Deno.systemMemoryInfo()

Similarly to other permission flags, you can grant access to APIs granularly by providing an allow list of APIs, eg. --allow-sys=hostname,osRelease.

Improvements to npm support

This release fixes a lot of bugs related to npm specifiers and adds several new features. Support for npm modules is still experimental and requires the --unstable flag.

--node-modules-dir flag

npm specifiers resolve npm packages to a central global npm cache. This works well in most cases and is ideal since it uses less space and doesn’t require a node_modules directory. That said, you may find cases where an npm package expects itself to be executing from a node_modules directory. To improve compatibility and support those packages, a new --node-modules-dir flag has been added.

For example, given main.ts:

import chalk from "npm:chalk@5";

console.log(chalk.green("Hello"));

Running this script with a --node-modules-dir like so…

deno run --unstable --node-modules-dir main.ts

…will create a node_modules folder in the current directory with a similar folder structure to pnpm.

Note that this is all done automatically when calling deno run and there is no separate install command necessary.

In the case where you want to modify the contents of the node_modules directory before execution, you can run deno cache with --node-modules-dir, modify the contents, then run the script. For example:

deno cache --unstable --node-modules-dir main.ts
deno run --allow-read=. --allow-write=. scripts/your_script_to_modify_node_modules_dir.ts
deno run --unstable --node-modules-dir main.ts

--reload=npm: and --reload=npm:<package>

The --reload flag reloads external resources that were previously cached. This release adds more targeted --reload=npm: and --reload=npm:<package> support.

For example, to reload all npm packages use the --reload=npm: flag when running your script:

deno run --unstable --reload=npm: main.ts

Or to reload just a single package, such as chalk:

deno run --unstable --reload=npm:chalk main.ts

--compat mode removed

In order to not have two separate execution modes, the unstable --compat mode has been deprecated in favor of npm specifiers.

Future improvements

We’ll continue working on npm support and land TypeScript & editor integration within the coming weeks. For our full npm specifier roadmap, see https://github.com/denoland/deno/issues/15960

Node.js compatibility improvements

Deno v1.26 includes implementations for several previously unsupported APIs in the Node.js compatibility layer. Additionally, the entire compatibility layer’s test suite has been updated for compatibility with Node.js v18.8.0. Previously, the test suite targeted Node.js v16.13.0. This change was made in preparation for Node.js 18 entering Long Term Support (LTS) in October.

Please note that the entire Node.js compatibility layer still requires the use of the --unstable flag.

Streams refactoring

The Node.js streams implementation in Deno has been updated to use the readable-stream@4.1.0 npm module. This change will allow Deno to better keep up with breaking changes and new features. For more context on this decision, please see this blog post.

Within the compatibility layer, the stream and stream/promises modules are now implemented via readable-stream. This refactor also introduces several new APIs, including Readable.toWeb(), Writable.toWeb(), and Duplex.toWeb() which are used to convert various types of Node.js streams to Web streams.

The fs.ReadStream and fs.WriteStream implementations have also been updated to improve compatibility with the implementations in Node.js. Thanks to @PolarETech for this work.

child_process APIs

The child_process module has added support for spawnSync(), exec(), execSync(), and execFileSync().

Thanks to @iuioiua and @PolarETech for contributing spawnSync() and exec(), respectively.

process.getuid() and process.getgid()

On non-Windows platforms, the user identifier and group identifier of the process can be accessed via process.getuid() and process.getgid(). On Windows this functionality does not exist, and these methods are undefined.

Thanks to @iuioiua for contributing this feature.

Changes to Deno APIs

API stabilizations

The following APIs have been stabilized in this release and no longer require the --unstable flag to be used.

• Deno.hostname()
• Deno.refTimer()
• Deno.unrefTimer()

Unstable Deno.stdin.setRaw() API

In this release, the unstable Deno.setRaw(rid) API has been removed in favor of Deno.stdin.setRaw(). We plan to stabilize this API in the next minor release.

Improvements to Deno.serve() API

We received a lot of positive feedback for the new unstable Deno.serve() API which provides a fast HTTP server.

In this release we fixed several reported bugs like spurious hangs on Windows, blocking of concurrent requests or partials writes.

We continue to improve our server implementation and want to stabilize this API in Deno v1.27.

Performance improvements

Over the last few releases, we have been making continual performance improvements as part of an internal initiative to find bottlenecks and reduce latency and processing overhead wherever we can. We will be writing about this work in more detail soon so keep an eye on the blog for updates. In the meantime, we can share some benchmarks we have done comparing the v1.24.3 release to the latest and greatest in this release.

Text encoding into an existing TypedArray sees a huge 5x improvement in max throughput for small payloads and up to 30x for larger payloads. See denoland/deno#15922.

Writing a small file is now 1.44x faster for synchronous write (Deno.writeFileSync()) and 1.15x faster for async (Deno.writeFile()).

CSV parsing performance regressed recently with a change we made in how we do our text encoding/decoding. We are working on bigger improvements here but this release sees a nice bump of 1.36x on Mac and 1.19x on Linux in benchmarks we have done.

URL parsing is now up to 2.27x faster for Urls with no query string and 1.37x faster for a more complex Url with multiple query string parameters. See denoland/deno#15663.

There have been a number of recent improvements to file system operations with more to come. This is a summary of the kind of improvements you should see in this release compared to v1.24.3. On MacOS, Deno.copyFileSync now uses APFS’ copy-on-write clonefile syscall when possible. See denoland/deno#15873.

console.log() is now 5x faster for small payloads! denoland/deno#15931.

TTY methods like Deno.consoleSize are up to 2.4x faster compared to v1.24.3. denoland/deno#15976.

Improved module download UI

Deno got a new interactive “Download…” message display.

In non-TTY environments, Deno will fall back to previous way of displaying “Download …” on a separate line for each file.

Developer experience improvements

As mentioned recently we have been focusing on making Deno the smoothest developer experience. The past while we have had a team focused on doing that and one of the areas they have been tackling has been around discovery. Deno and the wider JavaScript/TypeScript ecosystem is vast and can be complex to navigate, and we have tried to make it easier for you to find what you are looking for.

Some of the things we have changed recently to try to make that experience better have been:

• An overhaul of the search capability on deno.land providing searches across the manual, third party modules, and the ability to search symbols across the built-in APIs, the Deno standard library (std), and all third party modules.
• Ranking search results and ordering third party module listing on deno.land/x by actual code usage. Previously this was ranked by GitHub stars, which provided a very skewed view of the Deno third party ecosystem.
• Integrated documentation on deno.land for built-in APIs categorizing each API to help make discovering the breadth of built-in capabilities of Deno easier to discover.
• An informative landing page and integrated auto-generated documentation for each third party module. For example checkout out the documentation for oak.
• Improvements to how the documentation is indexed, discovered, and shared by search engines and social media. Just improving the search on deno.land may not benefit everyone trying to discover Deno or attempting to share information about Deno.
• Upped our game in understanding how the Deno ecosystem behaves and is connected. We have been deep diving into the data available to try to continue to identify gaps in information and continually improve the discovery experience.

Things that will be coming in the near future:

• Auto-linking between symbols within documentation, including between symbols and documentation. This will make it easier to explore a module or API.
• A dependency listing for each third party module on the landing page, making it easier to understand how a third party module is connected.
• Provide more information about the popularity, quality, and maintenance of third party modules.
• A view of the npm ecosystem from a Deno perspective, making it easier to discover and use npm packages in Deno.
• An overhaul and restructure of the manual to make the information contained more clear and relevant to those discovering and exploring Deno.

While we have been focused on the discovery aspect recently, we are also forming plans to re-focus on making the intelligent editor experience even better as well as improve the experience around the built-in tools within the Deno CLI.

TypeScript 4.8

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