はじめに

Deno v2.7がリリースされました。

この記事では主な変更点などについて紹介します。

deno compile --self-extracting

deno compileコマンドに--self-extractingオプションが追加されています (#32227)

例えば、以下のファイルがあったとします。

  • main.js:

    import { readData } from "./read_data.js";
    console.info(await readData());
    
  • read_data.js:

    export async function readData() {
      const data = await Deno.readTextFile(import.meta.dirname + "/data.txt");
      return data;
    }
    
  • data.txt:

    Hello, Deno!
    

この状態で--self-extractingを指定して実行可能ファイルを作成します。

$ deno compile --self-extracting --output foo -R=data.txt --include=data.txt main.js

そして、作成された実行可能ファイルを実行します。

$ ./foo
Hello, Deno!

すると、実行可能ファイルと同一ディレクトリに<実行可能ファイル>.fs/<ハッシュ>ディレクトリが作成されます (<ハッシュ>はDenoのバージョン及び各種ファイルの内容から計算されます)

$ ls foo.fs/6b768ca39a1ab3f1
data.txt  main.js  read_data.js

このように--self-extractingを指定して作成された実行可能ファイルは、実行可能ファイルに埋め込まれたファイルを実際のファイルシステム上 (extraction directory) へ出力します。ファイルシステム関連のAPIが実行される際は extraction directory に書き込まれたファイルに対して操作が実行されます。例えば、意図的に extraction directory 上のファイルを削除してから実行可能ファイルを実行すると、操作が失敗します。

$ rm foo.fs/6b768ca39a1ab3f1/data.txt

$ ./foo                              
error: Uncaught (in promise) NotFound: No such file or directory (os error 2): readfile '/path/to/project/foo.fs/6b768ca39a1ab3f1/data.txt'
  const data = await Deno.readTextFile(import.meta.dirname + "/data.txt");

この仕組みにより、Node.js addons に依存した実行可能ファイルの実行など、より様々なユースケースに対応できるようにすることが想定されているようです。

ただし、#32227 にて記載されていますが、--self-extractingを使用しない場合と比較すると、extraction directory 上のファイルの改ざんなどによるセキュリティリスクも考えられるため、必要な場合以外はむやみな使用は避けると良さそうです。

deno create

deno createコマンドが追加されています (#32225)。

機能としてはdeno init --npmコマンドとほぼ同じで、引数としてnpm:<package>を指定すると、npm:create-<package>パッケージを実行できます:

# `npm:create-hono`パッケージが実行されます
$ deno create npm:hono

また、deno createコマンドではjsrパッケージによるプロジェクトの作成もサポートされています (#32229)。例えば、deno create jsr:@<scope>/<package>のように指定された合、jsr:@<scope>/<package>/createが実行されます:

# `jsr:@uki00a/foo/create`が実行されます
$ deno create jsr:@uki00a/foo

これに合わせて、deno initコマンドで--jsrオプションがサポートされています。

deno check --check-js

deno checkコマンドに--check-jsオプションが追加されています (#32235)

効果はcompilerOptions.checkJs: trueを指定した場合と同様で、JavaScriptファイルに対する型チェックが有効化されます。

deno add --save-exact

--save-exact (--exact)がサポートされています (#31977)

挙動はnpmにおける同名オプションと同様です。

$ deno add --save-exact npm:picocolors

$ cat deno.json | jq .imports.picocolors
"npm:picocolors@1.1.1"

deno install -g

npmパッケージインストール時の振る舞いの変更

deno install -gでnpmパッケージがインストールされる際に、${DENO_INSTALL_ROOT}/bin/.<パッケージ>ディレクトリを作成し、該当パッケージの実行時にそのディレクトリが利用されるよう挙動が変更されています。このディレクトリには該当パッケージの依存関係を保存するnode_modulesディレクトリやdeno.jsonなどが保存されます (#32302)

$ deno install -g npm:cowsay

$ ls ${DENO_INSTALL_ROOT}/bin/.cowsay
deno.json  deno.lock  node_modules  package.json

$ cat ${DENO_INSTALL_ROOT}/bin/.cowsay/deno.json
{
  "workspace": [],
  "nodeModulesDir": "manual"
}

ライフサイクルスクリプトに依存したnpmパッケージとの互換性の改善などを目的としているようです。

deno install -g --compile --allow-scripts

deno install -g --compile--allow-scriptsがサポートされています。ライフサイクルスクリプトに依存したnpmパッケージについて、ライフサイクルスクリプトの実行後にコンパイルが実行されます (#32249)

deno install -g --compile -f

deno install -g --compile-fオプション (--force) がサポートされています (#32242)

コンパイル済みのファイルがすでに存在する場合、それを上書きしてインストールし直してくれます。

deno task

deno.jsontasksに記載するスクリプトの実行においてfailglobオプションが無効化されました (#32223) (dax v0.45.0でも同様の変更が実施されています)

以前までの挙動に戻したい場合はshopt -s failglobの実行が必要です。

deno upgrade

deno upgradeコマンドによってインストールされたアーカイブをキャッシュする仕組みが導入されています (#32187)。もしアップデート先のバージョンのアーカイブがキャッシュされていた場合は、それが再利用されます。

アーカイブは${DENO_DIR}/dl/release/<version>または${DENO_DIR}/dl/canary/<version> (canaryバージョンへのアップデートの場合) にキャッシュされます。

また、canaryバージョンのアーカイブのキャッシュは最大で10個まで保持され、それを超過する場合はcanaryバージョンへのアップデート後に古いものから削除されます。

deno audit --ignore

deno auditコマンドで--ignoreオプションがサポートされています (#32221)

CVEのIDを指定することで、特定のレポートを除外できます。

deno deploy

deno.jsondeploy.include 及び deploy.exclude フィールドが追加されています (#32254)

Deno Deployアプリケーションのデプロイメントに含めるまたは除外するファイルを指定できるようです。

deno bundle --keep-names

deno bundleコマンドに--keep-namesオプションが追加されています (#32285)

esbuildの同名オプションと同様に、バンドル後も関数やクラス名を維持してくれます。

deno fmt --check

--fail-fastオプションがサポートされています (#31438)

効果はdeno testの同名オプションと同じで、フォーマットエラーが検出された段階で後続のファイルに対するチェックをスキップしてくれます。

deno lsp

deno lspにおいてtypescript-goベースの実装の追加が開始されています (#32016, #32251, #32303)

有効化するためにはDENO_UNSTABLE_TSGO_LSPの指定が必要です。

Permissions

今まで、/proc/pressure/配下のファイルを読み込むには--allow-allの指定が必要でしたが、--allow-readの指定のみで読み込めるよう挙動が変更されています (#30780)

Web API

Temporal API

Temporal APIが安定化されています (#31928)

--unstable-temporalを指定せずにTemporal APIを使用できます

CompressionStream/DecompressionStream

CompressionStream及びDecompressionStreamでBrotliがサポートされています (#32028)

コンストラクタのformat引数に "brotli" を指定すると利用できます。

navigator.platformが実装されています (#30795)

WebAssembly

WASMに関するスタックトレースのフォーマットがWebAssembly specificationにて言及されているフォーマットで出力されるよう改善されています (#32293, #32246)

Deno API

Deno.FsFile#tryLock()

FsFile#tryLock()及びFsFile#tryLockSync()が実装されています (#31848)

Deno.FsFile#lock()とは異なり、ロックが獲得できない場合は即座にfalseを返却してくれます。

Deno.spawn()

実験的APIとして下記3つのAPIが追加されています (#32238)

  • Deno.spawn()
  • Deno.spawnAndWait()
  • Deno.spawnAndWaitSync()

それぞれDeno.Command#spawn(), Deno.Command#output()及びDeno.Command#outputSync()のショートハンドとして機能します。

const { stdout } = await Deno.spawnAndWait(Deno.execPath(), ["info"]);
console.info(new TextDecoder().decode(stdout));

Node.js

package.json

package.jsonoverridesがサポートされています (#32073)

npmと同様に、推移的に依存されているパッケージのバージョンの固定などが可能です。

node:util

parseEnv()が実装されています (#32183)

node:process

下記APIが追加されています。

  • process.config.variables.host_arch (#32265)
  • constrainedMemory() (#32209)
  • availableMemory() (#32200)

node:fs

openAsBlob()が実装されています (#32261)

node:child_process

spawn()timeoutkillSignalオプションがサポートされています (#32283)

また、fork()の第1引数でURLオブジェクトの指定がサポートされています (#32268)

node:http

request()でIPv6形式のホスト名によるリクエストがサポートされています (#32258)

また、request()keepAlive: trueが設定されたAgentを使用している場合、リクエストボディをpipeline() (node:stream/promises) などによってストリーミングしていると、リトライ時にリクエストボディーがうまく送信されない問題が修正されています(#32215)

参考情報