Deno v2.0.0-rc.5/v2.0.0-rc.6/v2.0.0-rc.7がリリース

Denoのv2.0.0rc.5〜v2.0.0 rc.7がリリースされています:

--allow-importの導入

--allow-importという新しいパーミッションフラグが導入されています (短縮形式は-I)

Deno v2からリモートモジュールの読み込みを許可するホストに制限がかかるようです。必要に応じて--allow-importにリモートモジュールの読み込みを許可するホストを指定する必要があります。

ただし、デフォルトで以下のホストからのモジュールのimportが許可されるようなので、基本的なケースにおいては今まで通り利用できると思われます:

例えば、unpkg.comからモジュールをimportしようとすると、上記のいずれのホストにも当てはまらないため、権限が要求されます:

import ky from "https://unpkg.com/ky@1.7.2";

const res = await ky.get("https://api.github.com/repos/uki00a/deno-weekly").json();

この場合、以下のように権限が求められます:

$ deno run --allow-net main.js
┏ ⚠️  Deno requests import access to "unpkg.com:443".
┠─ Requested by `import()` API.
┠─ Learn more at: https://docs.deno.com/go/--allow-import
┠─ Run again with --allow-import to bypass this prompt.
┗ Allow? [y/n/A] (y = yes, allow; n = no, deny; A = allow all import permissions) > 

--allow-importによってunpkg.comを明示的に許可すると、権限が求められなくなります:

$ deno run --allow-net --allow-import=unpkg.com main.js

ただし、--allow-importを明示した場合、デフォルトで許可されるdeno.landjsr.ioなどのホストに対しても権限が必要となるため、必要に応じてそれらのホストも許可する必要がありそうです:

# unpkg.comとjsr.ioからのimportのみを許可します
$ deno run --allow-net --allow-import=unpkg.com,jsr.io main.js

また、deno runの引数でリモートのURLが指定された場合、デフォルトでそのホストからのimportが許可されるようです。


破壊的変更

deno.json

deno.jsonimportMapオプションでのリモートのImport mapsの指定が廃止されました。(もし需要があれば、今後、よりセキュアな方法によって再度サポートを導入することも考慮されているようです)

--import-mapなどでは引き続きリモートのImport mapsが指定できるので、そちらへの移行が推奨されます。


Deno.UnsafeWindowSurface

Deno.UnsafeWindowSurfaceconstructorのシグネチャーが変更されています。引数として単一のoptions引数を受け取るように変更されており、必須のオプションとしてwidthheightが追加されています。

この変更に合わせて、GPUCanvasConfigurationからwidthheightプロパティーが削除されています。


Deno.errors.BadResourceについて

今まで以下のエラーについてDeno.errors.BadResourcethrowされていましたが、代わりにDeno.errors.Busythrowされるように挙動が変更されています:

  • TCP stream is currently in use
  • Listener is currently in use
  • UNIX stream is currently in use (エラーメッセージもUnix socket is currently in useに変更されています)

deno fmt

HTML/CSS/YAMLサポートの安定化

Deno v1.46で導入されたdeno fmtのCSS/HTML/YAMLサポートが安定化されました。--unstable-cssなどのオプションやdeno.jsonでの"unstable": ["fmt-html"]の指定などをせずとも、これらの形式のファイルがフォーマットされます。


deno fmt --check

CSS/HTML/YAML形式のファイルに対してdeno fmt --checkを実行すると、常にエラーとして扱われてしまう問題も修正されています。


NunjucksとVentoのサポート

deno fmt.njk.vto形式がサポートされています。これらの形式のファイルをフォーマットするには--unstable-componentの指定が必要です。


deno add

deno addでnpmパッケージを追加する際に、バージョンが省略された場合はデフォルトでlatestタグに設定されたバージョンがインストールされるよう振る舞いが変更されています


deno compile

RCバージョンでもdeno compileが動作するように改善されています。


TypeScript

compilerOptions.noImplicitOverride

リモートモジュールに対してcompilerOptions.noImplicitOverrideが適用されないよう挙動が修正されています。


Node.js互換性の改善

--node-modules-dir

--node-modules-dirオプションに値が指定されなかった場合、--node-modules-dirが無視されてしまっていた問題が修正されています。autoがデフォルト値として使われます。


静的解析が困難なCJSモジュールの取り扱いが改善

静的な解析が困難なCJSファイルのimport時にエラーが発生する問題が改善されています。

主にRsbuildの動作に向けた対応のようです。

また、Denoの公式ドキュメントにCommonJSサポートに関する解説が追加されています。


Conditional exportsサポートの改善

Conditional exports"node"に指定されたパスが解釈されるよう振る舞いが改善されています。

これがサポートされていなかったことで、nuxt buildによって生成されたサーバーをDenoで動かせない問題があったようです。


require(esm)

ESM形式のモジュールをrequireしようとするとパニックすることがある問題が改善されています。


process.stdin.pause

create-viteがハングする問題を解消するため、process.stdin.pauseの振る舞いが修正されています。


CLI

サブコマンドよりも前の位置にDenoのCLI引数(--allow-netなど)が指定された際に、エラーが発生するように振る舞いが改善されています (今までは単純に無視されていたようです)

$ deno --allow-read run main.js
error: unexpected argument '--allow-read' found

  tip: 'run --allow-read' exists

Usage: deno run [OPTIONS] [SCRIPT_ARG]...

--allow-allに関する振る舞いの変更

--allow-allとその他の--allow-*フラグが併用された際に、エラーが発生するように振る舞いが変更されています


Web API

globalThis.location

globalThis.locationconfigurable: trueに変更されています。主にVitest 2の動作に向けた対応のようです。


Web Crypto API

SubtleCryptoimportKeyexportKeyでP521 EC鍵がサポートされています。


@deno/vite-plugin

Deno公式からViteプラグインが公開されています:

npm:/jsr:/https:のサポートや、deno.jsonで定義されたImport mapsの解決などがサポートされているようです。

deno_stdのリリース

deno_stdがリリースされています (release-2024.09.24)

@std/archive@0.225.4

@std/archive@0.225.4がリリースされています。

@std/archiveが非推奨化されており、今後は@std/tarへの移行が推奨されます。

@std/io@0.224.9

@std/io@0.224.9がリリースされています。

以下のAPIが非推奨化されており、@std/streamsへの移行が推奨されています:

非推奨化されたAPI移行先
BufWriterBuffer (@std/streams/buffer)
BufReaderBuffer (@std/streams/buffer)
StringWriterBuffer.writable (@std/streams/buffer)
StringReaderBuffer (@std/streams/buffer)
LimitedReaderLimitedBytesTransformStream (@std/streams/limited-bytes-transform-stream)
MultiReadermergeReadableStreams (@std/streams/merge-readable-streams)
readDelimByteSliceStream (@std/streams/byte-slice-stream)
readLong-
readRangeByteSliceStream (@std/streams/byte-slice-stream)
readInt-
readShort-
sliceLongToBytes-
readStringDelimTextDelimiterStream (@std/streams/text-delimiter-stream)
copyNByteSliceStream (@std/streams/byte-slice-stream)
readLinestoLines (@std/streams/unstable-to-lines)

@std/collections@1.0.7

@std/collections@1.0.7がリリースされています。

配列を引数として受け取る各種APIでIterableをサポートするための対応が行われています。現状では、Iterableのサポートはunstable-プレフィックスがついたモジュールから利用できます:

  • sample (@std/collections/unstable-sample)
  • withoutAll (@std/collections/unstable-without-all)
  • chunk (@std/collections/unstable-chunk)
  • sortBy (@std/collections/unstable-sort-by)
  • takeWhile (@std/collections/unstable-take-while)

@std/http@1.0.7

@std/http@1.0.7がリリースされています。

@std/http/unstable-routeRoute.methodに配列で複数のメソッドを指定できるように改善されています。

@std/expect@1.0.4

@std/expect@1.0.4がリリースされています。

expect.hasAssertions()が実装されています。

@std/streams@1.0.6

@std/streams@1.0.6がリリースされています。

新しいAPIとしてtoBytes (@std/streams/unstable-to-bytes)が追加されています。ReadableStream<Uint8Array>を受け取り、そこから読み込まれたデータを結合して結果をPromise<Uint8Array>として返却してくれます。

@std/assert@1.0.6

@std/assert@1.0.6がリリースされています。

各種assert*関数でabstract classを引数として受け取れるように型定義が改善されています。

@std/text@1.0.7

@std/text@1.0.7がリリースされています。

levenshteinDistance (@std/text/levenshtein-distance)においてU+FFFFよりも大きいコードポイントが適切に取り扱われない問題が修正されています。

@types/deno

DefinitelyTypedに@types/denoパッケージが追加されています:

DenoのAPIに関する型定義が提供されるようです。


Deno 2.0 rcでreactとnext.jsの設定を試す

Deno v2.0.0-rc.4を使ってNext.jsを動作させる記事が公開されています:

Slack Platform(Deno)を活用したインシデント対応標準化の取り組み

Slackの開発プラットフォームとDenoの活用に関する記事が公開されています:

rusty_v8の安定版がリリース

deno_coreの内部で使用されているrusty_v8の安定バージョンが公開されたようです:

これに合わせてバージョニングに関する方針が変更されるようで、今後はChromeのバージョニングと同様の方式で運用が行われるようです。例えば、rusty_v8 v129.0.0ではChrome v129に合わせてV8のv12.9.a.bが使用されるようです。