As mentioned in the recent “Forced Optimization” presentation at Node Congress 2023, we’re working diligently towards a major release of Deno 2 in the coming months. Though our vision for Deno 2 is ambitious, our goals haven’t changed since we started the project:

Effortless Coding: Whether that’s removing config, boilerplate code, or build steps, we’ve continued to make it easy for you to dive into code and be productive immediately. This release made our LSP more robust, allowing any code editor with LSP support to work great with Deno projects.

Best-in-Class Performance: Speed and efficiency is important for developers and users. This release improved the performance of HTTP and WebSocket servers, as well as set the foundation for further performance work.

Uncompromising Security. Security was built into Deno with an opt-in permission model so you always know what your code has access to. In the coming months, we’ll be introducing new features to Deno’s permission system, making it easier and more flexible to work with.

Deno 1.33 is a step further towards these ideals. With this release:

• Built-in KV database
• Flatter deno.json configuration
• Fewer permission checks for dynamic imports
• Improvements to npm and Node compatibility
• Performance improvements
• Improvements to CLI
• LSP document preloading
• Changes to Deno APIs
• Changes to the standard library
• V8 11.4

As we approach Deno 2, the next minor releases will focus on improving performance, creating a best-in-class developer experience, enhancing security, and more robust Node/npm compatibility.

Built-in KV database

Deno KV is a seamlessly integrated database within Deno. With no dependencies to install, you can start building apps right away. Plus, when you deploy to Deno Deploy, your data is supported by a consistent, geo-replicated global database. Keep in mind that KV is currently an unstable API, so you’ll need the –unstable flag to use it.

Get started with KV in no time, and with zero setup:

const kv = await Deno.openKv();

const key = ["users", crypto.randomUUID()];
const value = { name: "Alice" };
await kv.set(key, value);

const result = await kv.get(key);
result.value; 

Of course, the data is both durable and persistent on disk, ensuring reliable storage and access even across program restarts.

For comprehensive documentation, explore the manual.

Flatter deno.json configuration

deno.json schema has been flattened to make it easier to read and write.

Nested options like "lint.files.exclude" or "fmt.options.lineWidth" are now available at the top level of their respective sections.

Instead of writing this:

{
  "lint": {
    "files": {
      "exclude": ["gen.ts"]
    }
  },
  "fmt": {
    "options": {
      "lineWidth": 80
    }
  }
}

You can now write this to the same effect:

{
  "lint": {
    "exclude": ["gen.ts"]
  },
  "fmt": {
    "lineWidth": 80
  }
}

All changes:

This change is backwards compatible, but we are gravitating towards deprecating the old schema in the future.

Thank you to @scarf005 for implementing this change.

Fewer permission checks for dynamic imports

This release brings a huge quality of life improvement when working with dynamic imports.

If you use a string literal in an import() call (eg. import("https://deno.land/std/version.ts")) Deno will no longer require a permission to execute this import. We have been able to download and analyze these kinds of imports for the long time and after discussions we decided it’s better to not require permission to execute this code - it is already a part of the “module graph” of your program and shows up in the output of deno info main.ts.

This change will make it make easier to conditionally execute some code in certain situations - for example, if you have a CLI tool that include many subcommands, you might want to conditionally load their respective handlers only when the subcommand is invoked. This greatly improves startup time of your tool. Another example is loading a polyfill only when it’s needed, or executing debugging code in your server application only in the presence of an environmental variable.

Keep in mind that permissions will still be checked for dynamic imports that are not statically analyzable (ie. don’t use string literals for the specifier):

import("" + "https://deno.land/std/version.ts");

import(`https://deno.land/std@${STD_VERSION}/version.ts`);

const someVariable = "./my_mod.ts";
import(someVariable);

Thank you to Nayeem Rahman for implementing this change.

Improvements to npm and Node compatibility

node:crypto, node:http and node:vm module have been greatly improved since the last release. We polyfilled most of the node:crypto APIs which unblocked many popular npm packages (including cloud provider SDKs). The changes to node:http and node:vm are especially helpful for Vite users, and Vite should now be much more stable and performant when used with Deno.

Full list of all the APIs that were implemented in this release:

• crypto.checkPrime
• crypto.checkPrimeSync
• crypto.createSecretKey
• crypto.createVerify
• crypto.ECDH
• crypto.generateKey
• crypto.generateKeyPair
• crypto.generateKeyPairSync
• crypto.generateKeySync
• crypto.generatePrime
• crypto.generatePrimeSync
• crypto.getCurves
• crypto.hkdf
• crypto.hkdfSync
• crypto.sign
• crypto.Sign
• crypto.verify
• crypto.Verify
• crypto.X509Certificate
• http.ClientRequest.setTimeout
• http.IncomingMessage.socket
• module.Module._preloadModules
• vm.runInThisContext

In terms of npm support, we greatly improved cache handling for npm packages. Starting with this release, Deno will try its best to retrieve information from the registry when it encounters a missing version (or a version mismatch) of a package in the cache. This should result in a lot fewer messages suggesting to use --reload flag to retrieve the latest registry information.

Performance improvements

This release we overhauled our implementations of the HTTP server and both client and server for WebSockets. Over the last few months we received feedback that Deno.serve and WebSocket APIs are not as performant and reliable as they should be.

We took this feedback to heart and are working tirelessly to improve them. While the changes in RPS benchmarks might not yet be visible in your applications, we took radical steps towards improving overall performance of these APIs that we will present in the coming months.

Improvements to CLI

deno bench - --no-run flag

This releases adds a new --no-run flag to the deno bench subcommand to cache all the resolved bench files without running them. This aligns deno bench with deno test.

> deno bench --no-run
Download https://deno.land/std@0.185.0/path/mod.ts
Download ...etc...
Check file:///home/user/project/main_bench.ts

Thanks to Geert-Jan Zwiers for contributing this feature.

deno task - unset command

A cross platform unset command was added to the shell in deno task to allow deleting environment and shell variables. This works the same as the POSIX unset command and doing MY_VAR= now correctly sets a variable to being empty.

{
  "tasks": {
    // `deno task example` outputs "1" then "false"
    "example": "export VAR=1 && echo $VAR && deno task next",
    "next": "unset VAR && deno eval 'console.log(Deno.env.has(\"VAR\"))'"
  }
}

LSP document preloading

In previous versions of Deno you might have found that certain functionality didn’t work unless you had previously opened a file. For example, doing “find references” on some code might not have shown it being used in a test file unless the test file had been previously opened. This issue is now mitigated by pre-loading files when initializing the language server, which should lead to a much better experience.

Note that as part of this preloading, the language server will walk a maximum of 1000 file system entries and output a log message when this is hit. In cases where this is an issue and the workspace has a lot of non-Deno related files, you may want to take advantage of the "deno.enablePaths" option to partially enable a workspace.

Changes to Deno APIs

We are deprecating the Deno.run API. With the stabilization of the Deno.Command API in v1.31 it is our recommended way to spawn subprocesses. Deno.run has a few quirks that proved hard to be resolved and we channeled most of our efforts into designing a better API that would be easier to use. Deno.run will be removed in v2.0, so we strongly encourage you to migrate your code to Deno.Command.

The unstable Deno.serve API receives a breaking change by removing one of the API overloads in preparation for stabilization of this API. Deno.serve(handler: Deno.ServeHandler, options: Deno.ServeOptions) overload has been removed and is no longer available in v1.33.

Please update your code to use one of the available overloads:

Deno.serve((_req) => new Response("Hello, world"));

Deno.serve({ port: 3000 }, (_req) => new Response("Hello, world"));

Deno.serve({
  onListen({ port, hostname }) {
    console.log(`Server started at http://${hostname}:${port}`);
    
  },
  handler: (_req) => new Response("Hello, world"),
});

We intend to stabilize Deno.serve next month and it should will be the preferred API to use over Deno.serveHttp.

Changes to the standard library

Breaking changes to std/encoding module

As announced in the previous release post, the following 6 encoding modules have been moved to the top-level.

• 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

In this release, these deprecated modules are completely removed. If you haven’t migrated to the new paths, please update your import specifiers to them.

Note: If you don’t depend on these removed paths directly, but your transitive dependencies depend on these paths incorrectly with an non-versioned module URL, you might be unable to fix the issue by updating your own source code. In that case, please use an import map of the following pattern:

{
  "imports": {
    "https://deno.land/std/encoding/yaml.ts": "https://deno.land/std@0.179.0/encoding/yaml.ts"
  }
}

This forces a remap of non-versioned standard library URLs (in this case https://deno.land/std/encoding/yaml.ts) to a versioned one (https://deno.land/std@0.179.0/encoding/yaml.ts) in your entire dependency graph, and will fix the issue in your dependencies.

Deprecation of fs.exists has been canceled

exists and existsSync in std/fs module were once deprecated in v0.111.0, but their deprecations have been canceled in this release.

These APIs were deprecated because of their error prone nature. They are easy to cause race condition bug, known as TOCTOU. However after its deprecation there was a long discussion about correct/decent usages about them. The balance between their convenience and error-proneness having been reconsidered, they were decided to be restored.

Updates to std/csv module

In this release, the CsvStringifyStream API has been added. This API transforms the source streaming input into the stream of csv rows.

import { CsvStringifyStream } from "https://deno.land/std@0.185.0/csv/mod.ts";
import { readableStreamFromIterable } from "https://deno.land/std@0.185.0/streams/mod.ts";

const file = await Deno.open("data.csv", { create: true, write: true });
const readable = readableStreamFromIterable([
  { id: 1, name: "one" },
  { id: 2, name: "two" },
  { id: 3, name: "three" },
]);

await readable
  .pipeThrough(new CsvStringifyStream({ columns: ["id", "name"] }))
  .pipeThrough(new TextEncoderStream())
  .pipeTo(file.writable);

Following the above addition, CsvStream has been renamed to CsvParseStream to clarify its purpose.

Thank you to Yuki Tanaka for the contribution.

V8 11.4

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

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

• Resizable ArrayBuffer and growable SharedArrayBuffer
• ArrayBuffer.prototype.transfer, ArrayBuffer.prototype.transferToFixedLength and ArrayBuffer.prototype.detached