Deno 1.33: Deno 2 is coming

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