release

Deno v1.22がリリースされました。 この記事では、主な変更点についてまとめていきます。 リモートモジュールの型チェックがデフォルトで無効化 deno runやdeno testなどの各コマンドでリモートモジュールの型チェックがデフォルトで無効化されました。 今後はローカルのTypeScriptファイルのみが型チェックされます。 もしリモートモジュールの型チェックも必要な際は--check=allオプションまたはdeno check --remoteを使用します。 また、次のv1.23のリリースでは、deno runやdeno cacheではデフォルトで一切型チェックが行われなくなる予定です。 (deno checkコマンドや--checkオプションなどで明示的に型チェックする必要があります) 例えば、CIでdeno cacheコマンドを実行して型チェックを行っている場合などは、今のうちにdeno checkコマンドに移行しておくとよいと思います。 # mod.tsの型チェックを行う $ deno check mod.ts # deno run実行時に型チェックも行う $ deno run --check main.ts 設定ファイルの読み込みの無効化 Denoはエントリポイントが存在するディレクトリまたはその上位のいずれかのディレクトリにdeno.json(c)というファイルが存在する場合、それを自動で読み込みます。 このリリースでは、新しく--no-configオプションがサポートされました。 このオプションを指定すると、deno.json(c)の自動探索を無効化できます。 $ deno run --no-config main.ts (破壊的変更) Worker内でデフォルトでDeno APIが有効化 今までは、Worker内でDeno.readFileなどのAPIを使用したい場合は、denoオプションによって明示的に有効化する必要がありました。 new Worker(new URL('./worker.js', import.meta.url).href, { deno: { namespace: true }, // Deno APIの使用を有効化 type: "module" }); 今後は上記のようにオプションを指定しなくても、Worker内で常にDenoのAPIを参照できます。 new Worker(new URL('./worker.js', import.meta.url).href, { type: "module" }); また、この変更の影響により、WorkerOptions....

Deno v1.21がリリースされました。 この記事では新機能や修正点などについて解説します。 deno checkコマンドの導入 新しいコマンドとしてdeno checkコマンドが追加されました。 挙動としては基本的にdeno cacheコマンドと同等で、与えられたモジュールの型チェック及びリモートモジュールのダウンロードを行います。 $ deno check mod.ts deno cacheコマンドとの違い deno cacheコマンドとの大きな違いとして、deno checkコマンドはデフォルトではリモートモジュールの型チェックを行いません。 deno checkコマンドでリモートモジュールの型チェックも行いたい場合は--remoteオプションを指定する必要があります。 deno runコマンドでの型チェックについて deno checkコマンドの追加による影響として、将来的にdeno runコマンドではデフォルトで型チェックが行われなくなる予定です。(Deno v1.21時点でもDENO_FUTURE_CHECK=1環境変数を設定することで、この挙動を有効化できます) 型チェックを行いたいときは、今回追加されたdeno checkコマンドまたはdeno run --checkで明示的に行う必要が出てきます。 新しいサブプロセスAPI (unstable) DenoにはDeno.run()というサブプロセスを生成するためのAPIがありますが、今回、新しく3種類のAPIが追加されました: Deno.spawn() (高レベル) Deno.spawnChild() (低レベル) Deno.spawnSync() (Deno.spawnの同期版) これらのAPIの利用にはDeno.run()と同様に--allow-runパーミッションが必要です。 また、これらのAPIの追加により、Deno.run()は非推奨化される予定のようです。 Deno.spawn() これは高レベルAPIという位置づけです。 指定したコマンドを実行し、そのコマンドの実行結果(status)や標準出力(stdout)及び標準エラー出力(stderr)への出力内容を返却してくれます。 const { stdout, status } = await Deno.spawn("echo", { args: ["foo"], }); console.assert("foo\n" === new TextDecoder().decode(stdout)); console.assert(status.success); コマンドの出力結果のみが必要で、細かな制御はいらない場合に便利かと思います。 Deno.spawnChild() こちらは低レベルAPIという位置づけです。 Deno.Reader/Deno.WriterではなくReadableStream/WritableStreamをベースに実装されています。 const child = Deno....

Deno v1.20がリリースされました。 この記事では新しく追加された機能などについて紹介します。 (破壊的変更) Deno.testのpermissionsオプションの挙動が変更 ⚠️ この変更はv1.20.1時点ではまだ反映されていません！ 現在、正式な修正用のPRが作成されており、おそらくv1.20.2で反映されるはずです https://github.com/denoland/deno/pull/14024 Deno.testやWorkerなどのAPIはpermissionsオプションにより実行時のパーミッションをカスタマイズできます: Deno.test({ name: "permissions_test", permissions: { read: true }, fn: async () => { const content = await Deno.readTextFile("./data.txt"); await Deno.writeTextFile("./data.txt", processContent(content)); }, }); 上記のテストコードはDeno.readTextFileとDeno.writeTextFileを実行しており、正しく実行するためには--allow-readと--allow-writeの両方の権限が必要です。 このテストケースでは、下記宣言により--allow-readを明示的に指定しています。 permissions: { read: true }, ここではwrite: trueが指定されていないため、このテストケースは権限エラーにより失敗するというのが直感的な挙動なのではないかと思います。 しかし、Deno v1.19時点では上記のテストコードは成功してしまいます。 permissions: { read: true }, 実は、Deno v1.19において、この指定は下記宣言と同義になります: // `read`以外はすべてCLIオプションで指定された権限(--allow-writeなど)が継承される permissions: { read: true, env: "inherit", ffi: "inherit", hrtime: "inherit", net: "inherit", run: "inherit", write: "inherit", }, この挙動は直感的ではないということで、Deno v1....