Deno 1.10 overhauls test runner


Deno 1.10, the latest version of the security-focused runtime for JavaScript and TypeScript, improves the built-in test runner and adds a Web Storage API. The update was published May 11.

In Deno 1.10, the deno test test runner runs discovered test modules in isolation using a new instance of the runtime for each module. Previously, Deno ran tests serially inside a single runtime instance. Further, deno test now supports the --jobs flag to specify how many threads should be used when running tests. Tests still run serially by default.

Deno 1.10 also introduces configurable permissions for tests, using a permissions option; the ability to type check code examples in documentation comments, using the --doc flag; the ability to watch for file changes to re-run relevant test cases, using the --watch flag; and better test runner output. In future releases, support will be added for running code examples as regular tests.

Deno 1.10 follows last month’s release of Deno 1.9. To upgrade to Deno 1.10, users can run deno upgrade. Other improvements in Deno 1.10:

  • For Web Workers, the structured clone algorithm is leveraged to improve serialization. Web Workers allow developers to run multiple bits of JavaScript, TypeScript, and WebAssembly concurrently in separate execution environments, with communication between workers and the main thread done by passing messages.
  • Support has been added for a Web Storage API, which consists of localStorage and sessionStorage. This can be used to store a small amount of data persistently, without direct file access.
  • Atomics and shared memory in WebAssembly are enabled by default.
  • Support is offered for the deno-fmt.ignore file directive for Markdown files to skip file formatting; deno-fmt is a formatter based on dprint, which is able to format JavaScript, TypeScript, JSON, and Markdown files.
  • Users no longer have to store import maps on the local file system; import maps can be stored remotely and loaded over HTTP.
  • The --unstable flag is no longer required for CLI features; the flag now controls only the availability of unstable runtime APIs.

Copyright © 2021 IDG Communications, Inc.



Source link