Deno 1.10 Release Notes

Deno 1.10 has been tagged and released. It includes new features, performance improvements, and bug fixes.

Most notably:

  • Improvements to the built-in test runner
  • Structured cloning is supported in Web Workers
  • Added network storage API
  • Remote map import is supported

If you already have Deno installed, you can upgrade to 1.10 by running Deno Upgrade. If you are installing Deno for the first time, you can use one of the methods listed below.

# Use Shell (macOS and Linux). Curl - fsSL # https://deno.land/x/install/install.sh | sh using PowerShell (Windows). Use Homebrew iwr https://deno.land/x/install/install.ps1 - useb | iex # (macOS). Brew install deno # using Scoop (Windows). Scoop Install deno # Uses Chocolatey (Windows): Choco Install DenoCopy the code

rightdeno testThe improvement of

Deno 1.10 brings a major overhaul to the built-in test runner.

Isolation and parallel execution of tests. Prior to this release, Deno ran all tests serially in a single runtime instance. All discovered test modules are now run in isolation, with each module using a new runtime instance. Deno Test now supports the — Jobs flag, which allows people to specify how many threads should be used when running tests. By default, all tests are still run serially.

Configurable permissions for tests. Deno has flags that allow you to specify the permissions a program is allowed to use. To make it easier to test your program under different permission sets, deno.Test now supports the Permissions option, which allows you to specify the exact permissions to apply to test cases.

Deno.test({name: "write only", permission. {write: true, read: false}, async fn() {await deno.writetextFile ("./foo.txt", "I can write!" ). The console. The log (await Deno. ReadTextFile (". / foo. TXT ")). }});Copy the code

Note that despite providing –allow-read, we still get the expected failure.

$deno test - allow - read - allow - write - unstable test_permissions. Check file:///Users/ry/src/deno/test_permissions.ts ts From file:///Users/ry/src/deno/test_permissions.ts run a test. The test only writes... Failed (5ms) Failed. Only write PermissionDenied: Need read permission on "./foo. TXT ", At deno:core/core.js:86:46 at unwrapOpResult (deno:core/core.js:106:13) at async open (deno:runtime/js/40_files.js:46:17) at async Object.readTextFile (deno:runtime/js/40_read_file.js:40:18) at async fn (file:///Users/ry/src/deno/test_permissions.ts:6:17) at async asyncOpSanitizer (deno:runtime/js/40_testing.js:21:9) at async resourceSanitizer (deno:runtime/js/40_testing.js:58:7) at async exitSanitizer (deno:runtime/js/40_testing.js:85:9)  at async runTest (deno:runtime/js/40_testing.js:199:7) at async Object.runTests (deno:runtime/js/40_testing.js:244:7) Failed. Write only test results. FAILED. 0 pass; 1 failed; Zero are ignored; 0 were measured; 0 filtered out (37ms)Copy the code

Keep in mind that the test case requires no more permission than is granted to the process using the –allow-* flag. If a key is omitted in the “permissions “object, it inherits its value from its respective “allow-*” flag.

This feature requires the — Unstable flag.

Better test runner output. When running the test suite, each discovered module is shown a hint, including the number of tests and the source of those tests.

From file://dev/deno/cli/tests/unit/tty_test.ts run four tests. Test consoleSizeFile... Ok (11ms) test consoleSizeError... Ok (4ms) Test isatty... ok (4ms) test isattyError ... Ok (ms) from file://dev/deno/cli/tests/unit/rename_test.ts six test run. Test renameSyncSuccess... Ok (17ms) Test renameSyncReadPerm... Ok (5ms) test renameSyncWritePerm... Ok (6ms) test renameSuccess... Ok (13ms) test renameSyncErrorsUnix... Ok (34ms) Test renameSyncErrorsWin... Ignore (1 ms)...Copy the code

Examples of type checking in documentation. Keeping documentation up to date is critical to any project. It’s easy to forget to update a code sample after an API change, leading to code sample deterioration. To prevent this, deno Test now supports the –doc flag, which types check code samples in document comments.

/** * ``` * import { example } from "./test_docs.ts"; * * console.assert(example() == 42); Output function example(): string {return "example". }Copy the code

Try it yourself.

$deno test - doc https://deno.com/v1.10/test_docs.ts check file:///dev/test_docs.ts:2-7 errors. Ts2367 [error]. This condition will always return 'false' because the types of 'string' and 'number' do not overlap. The console. Assert (example () = = 42). ~~~~~~~~~~~~~~~ at file:///dev/test_docs.ts:2-7.ts:3:16Copy the code

In future releases, we plan to add support for running code samples as routine tests.

Pay attention to file changes when running tests. Deno Test now supports the — Watch flag, which will hold the process after completing the test and watch for file changes to rerun the relevant test case.

As with other subcommands that support the –watch flag, the files to be observed are automatically discovered by Deno.

Thanks to Casper Beyer and Liam Murphy for contributing these features.

Worker.postMessageSupports structured cloning algorithms

Web workers are the parallelization primitives of networks. They allow you to run multiple JavaScript, TypeScript, or WASM bits simultaneously in different execution environments (quarantines). You can communicate between these workers and the main thread by passing messages from one to the other.

Since the 1.0 release, Deno has supported web workers, but with one major limitation: until now worker.postMessage () used a nonconforming algorithm to internally JSON string-like messages. This solution presents some surprising pitfalls for users, as not all values and objects are properly serialized. This version changes that, allowing anyone who can use [Structured Clone Alogrithm] (developer.mozilla.org/en-US/docs/…

Here is an example of sending a recursive JavaScript object to the Worker that has previously failed.

const obj = { hello: "world" }; obj.self = obj; const worker = new Worker( "data:application/javascript,self.onmessage = (e) => self.postMessage(e.data);" . {type: "module"},); Worker.onmessage = (e) => {console.log("Received event:", e.ata). }; worker.postMessage(obj);Copy the code

Thanks to Tim Ramlot for this feature.

Support for Web storage apis

This release adds support for the Web Storage API. This API consists of localStorage and sessionStorage and can be used to persistently store small amounts of data without requiring direct access to the file system. The key to the data is the source (in Deno you can set it with –location). You can use localStorage and sessionStorage without any permissions.

The underlying storage layer and persistence are opaque to the application and therefore irrelevant to security.

The API works just like it does in a browser. LocalStorage can be used to store up to 5MB of data persistently across process restarts, while sessionStorage can be used to store a small amount of data within a process.

Here’s an example.

// kv.ts const key = Deno.args[0]; If (key == undefined) {// Display the number of entries console.log(localstorage.length) if the user does not pass any args. } else { const value = Deno.args[1]; If (value == undefined) {// If no value is specified, return the value of the key console.log(localstorage.getitem (key)). } else {// If a value is specified, set the value localstorage.setitem (key, value). }}Copy the code
$ deno run --location https://example.com ./kv.ts 0 $ deno run --location https://example.com ./kv.ts foo bar $ deno run --location https://example.com./kv.ts foo $deno run --location https://example.com./kv.ts 1Copy the code

Thanks to crowlKats, who contributed this feature.

Support deno-FMt-ignore-file for Markdown files

Deno FMT is a [dprint](https://dprint.dev/) -based formatter capable of formatting JavaScript, TypeScript, JSON, and Markdown files.

To skip the formatting of the file, use the deno-FMt-ignore-file directive and place it at the top of the file as a comment. Previously, these directives did not work in Markdown files, but as of 1.10, they are now supported.

To skip formatted Markdown files, use
.

Enable support for shared WASM memory.

This version enables support for atomic and shared memory in WebAssembly. This feature is already enabled by default in Chrome and Firefox, and is now available in Deno.

In the Webassembly. Memory constructor, setting shared to true enables atomization and allows the shared array buffer to be used as backup storage for WASM Memory.

Const memory = new webassembly. memory ({initial: 1). Is the largest. 10, shared: true, }); . The console. Assert (the memory buffer instanceof SharedArrayBuffer).Copy the code

In Deno, WASM threads are not yet possible due to the lack of support for transferring (sharing) array buffers to workers. This is a feature we want to introduce soon. To learn more about WASM thread information, you can read this blog] [Alex Danilo (developers.google.com/web/updates…

Remote map import is supported

Deno stabilized imported maps in Deno V1.8, after they were stabilized in Chrome 89. In 1.10, we enabled the use of remote import maps. This means that imported maps now do not need to be stored on the local file system; they can also be loaded over HTTP.

$ deno install --import-map https://example.com/import_map.json -n example https://example.com/mod.ts

Copy the code

Updated plug-in API

This version to refresh the plug-in interface, and allow them to use [serde_v8] (https://crates.io/crates/serde_v8) to implement the interface between runtime and local plug-in. This update provides all the necessary tools to schedule operations from a local plug-in without the need for third-party code. In addition, plugins are now allowed to access ResourceTable to store Rust objects within the runtime infrastructure. In terms of how to use these apis, Please refer to the [test_plugin] (https://github.com/denoland/deno/blob/0d319161bc19a520df653bc0c8386f14a68efbdb/test_plugin/src/lib.rs) Example. The plug-in system still needs the “Unstable” flag because it is an experimental feature.

Thanks to Elias Sjogreen for contributing to this refactoring.

Delete the unstable flag of CLI function.

Some parts of Deno are still unstable and may change destructively before they do — this mainly refers to JavaScript APIs. To use these apis, you need to specify the — Unstable flag when you run Deno. However, this flag is also used to flag some CLI features that are not yet stable (such as deno Lint). In 1.10, we removed the requirement to use the unstable flag for CLI functionality, so from now on, the unstable flag only controls the availability of unstable runtime apis. Some CLI features that are still considered UNSTABLE have appropriate annotations in their help text (UNSTABLE :). But they no longer need to use the — Unstable flag to run subcommands such as deno compile, deno lint.