Denoばた会議 Monthly 第25回

2024年1月5日開催。
connpassリンク。

今月のアップデートを追う

Denoのアップデートを追っていくLT。
そのあとの雑談込みでザックリと箇条書き。

@uki00aさんのスライド

Deno v1.39

WebGPU APIの再導入

• Deno v1.32で削除されたWebGPU APIがunstable APIとして再導入された
• { "unstable": ["webgpu"] }をdeno.json(c)に設定することで利用できる
• これに合わせてstd/webgpuも追加されている
• あまり使ってる方はいなさそう
• WebGPU API自体はモバイルだとまだ実装されていないので、toB向けなら使い道があるかも？

deno coverageのレポート形式

• Istanbulのような形式でサマリーレポートが表示される
• HTML形式でレポートを出力でき、こちらもIstanbulのような形式
• Jestは内部的にIstanbulを使っている
• JS界隈だと見慣れているものなので、これがいいだろうという感じ
• deno test --coverageで中間データを出す形式をやめようという動きが出ている
  • Jestが--coverageでHTMLレポートまで出す形式なので、それに合わせる形
• 今まであったどの行がカバレッジ的にダメかというのはオプションになった
  • 将来的にはdeno test --coverageをするときのデフォルトになる
• Jestに寄せていこうという考えになっている

deno compileでBYONMがサポート

• npmでインストールされた依存関係を使ってモジュール解決を行なう
• deno compile --unstable-byonmという形で認可する
• node_modules配下がdeno compileで含まれるようになる
• 実行ファイルはデカくなるかも
• ファイルサイズより実行できるかを重視した

sloppy imports(-unstable-sloppy-imports)

• sloppy importsを有効化すると、拡張子なしやディレクトリを指定したimportといったNode.jsのような記述ができる
• sloppyは『雑な』という意味
• これができると既存のNode.jsプログラムが動くようになる
• これがデフォルトになるという感じではない
  • これをつけるとCLI実行時に警告が出る
  • 移行をよりスムーズにしたい背景がある
• やろうという議論が出てきたわけではない
  • Davidさんが「これ作りました」と言って、Ryanさんたちも「え、これ作ったんだ」と驚いていた
    • Ryanさんは唯一のsloppy imports推進派だったが、LucaさんやKitsonさんから強く反対され諦めていた
    • そうしたらDavidさんが急に実装してきた
  • deno jupyterと同じノリ
  • deno coverageの変更も結構押し押しで提案した
    • deno coverageの変更はRyanさんが渋っているけど、LucaさんMarvinさんなどJSをよく使っているコアメンバーは好意的
    • Ryanさん一人の意思が強かったけど、Ryanさんの意思に反して出した機能が好評という例が出てきている

deno_stdのアップデート

std/expect

• Jest互換なexpect()APIが提供されている
• deno_std/testing/bdd.tsのdescribeとitを掛け合わせると、Jestのように書ける
• 去年末にスタックしてたコントリビュータの作業を引き取る形で進行した
• Deno Festの前後くらいに「これが進まないからJestから移行できない」という意見があり、それが原動力に
• Denoワールドを広げるためには必要な追加だったかな
• 比較的素直なAPI
• snapshotやexpect.anyが未サポートなど、完全サポートしたわけではない

std/cli

• コマンドライン引数の解析やスピナーなどのCLI関連のユーティリティなどが提供される
  • スピナーのデザインはoraというnpmモジュールを参考にしている
  • deployctlでx/waitっていうやつのスピナーを使っているので、std/cli/spinnerに移行してもよさそう
  • std/cli/spinnerの用例のようなtry { ... } finally { なんらかの終了処理 }のパターンを見ると、Explicit Resource Managementに対応させられないかなと思う
• CLI関係のユーティリティはstd/cliに入っていく
  • std/flagsというのがあったが使用範囲が限定的ということで、std/cli/parse_argsに移された
  • lambdalisueさんがcli/prompt_secretを入れてくださった
• ファクトリー関数は最近のJSのAPIだとなくなる傾向にあると教わった
  • classを返すようなものについては、new Class()というのが割とスタンダードな作り方らしい
  • Deno.Commandは最初Deno.commandとしてファクトリー関数だったけど、Lucaさんの発言からclass宣言に変わった

Fresh v1.6

Tailwind CSSが公式でサポート

• 大まかな手順
  • deno.json(c)でTailwind CSSのnpmモジュールをマッピング
  • 設定ファイルやstyle.cssなど通常のTailwind CSSと同じ工程で設定
  • Tailwind CSSプラグインを設定
• TwindよりTailwindのほうが使い慣れている人のほうが多いので、やりやすくなるかも
• Twindは微妙に非互換
  • Twind v1というのがTailwind CSS v3系と互換性がある
  • Twindの独自拡張があって、そこも互換性を下げている
• ランタイムビルドが本番だとできない？
  • 開発時はdeno task devでいけるはず
  • ランタイムビルドもできるのでは？
• パフォーマンスを上げるため、本番では事前ビルド推奨
  • deployctlを使ってCIでビルドすれば手間にならないし気にならないはず
• 一番推奨されるパターンが変わってきている
  • ビルドなしを推奨していたけど、Marvinさんに変わってから主流が変わってきた
  • Islandsの数が増えてくると、ビルドも重くなる
  • Freshを一番ヘビーに使っているdeco.cxが40秒くらい読み込み時間がかかっていたので、Islandsの事前ビルドに対応するようになった
  • それを踏まえるとスタイルの事前ビルドも必然と言える
  • 小規模であれば問題なかったことに甘えていた部分がある

FreshContextの導入

• HandlerやMiddlewareHandlerなどのctx引数に渡される型がFreshContextに変更されている
• 合わせて、以下の各型もFreshContextをベースに再定義されている
  • HandlerContext / MiddlewareHandlerContext
  • RouteContext
  • AppContext / LayoutContext
  • UnknownHandlerContext / ErrorHandlerContext
  • RouteContext以外は非推奨化されている
• FreshContextとRouteContextがわかれば使えるので、迷子になりやすさが減る
• Context型定義の種類が減るのはユーザーとして嬉しい

プラグインからのIslandsコンポーネントの提供がサポート

• プラグイン作者がislands配下のbaseLocationとpathsを設定することでユーザーにIslandsコンポーネントを提供できる
• プラグインを差すとカレンダーなどのUIライブラリ的なことができる
• エコシステムの発展に大事な機能かも
• アイランドアーキテクチャはマイクロフロントエンドと相性良さそうだけど、公式的な明言はない
  • 各チームがコンポーネントをプラグインとして配信して、それを組み合わせることでマイクロフロントエンドとは呼べるかも？
  • VueとReactを混ぜられるというマイクロフロント文脈とは少し違う

_fresh/staticのサポート

• _fresh/staticに置かれたファイルはstatic/ディレクトリに置かれたファイルよりも優先して配信される
• Tailwind CSSプラグインは、事前ビルド(deno task build)の実行時に_fresh/staticへビルド後のCSSファイルを出力される
• プラグインのビルド機能を使うときに使える
• ユーザーにビルド成果物を使わせることができる

質問共有コーナー

hashrockさんたちがDeno Deployダッシュボード改造計画やってる

• 成長具合を観察しつつ、改善をしている
• Aleph.jsを使っている
• 取り替えようと思っているけど、なかなか工数が取れない
  • Aleph.jsはRemixに近いSPA
  • ダッシュボードに入るとSPA的な動きになる
  • FreshはMPAなので、そこの解釈を変えるのが難しい
  • 全部載せ替えるなら3週間かかると試算して、それだったら別のことしたほうが良いという判断になった
• Deno Deploy開発者が一番のAlephの利用者であり、辛みがわかっている人
  • privateメソッドを使うと、しなくてもいいトランスパイルをして加えてミスるので、静かに崩壊する
  • Aleph.jsはSWCを独自にやっているので、そこが最新に追いついていないかも
  • 自分で使っていなくても、依存関係が使っていると巻き込んで連鎖崩壊するのが辛い
• Xiaさんいてほしかったな〜
  • 一時期、Deno Deployを一緒にやっていた方
  • Aleph.jsの制作者
• いわゆる技術的負債になっている
  • Reactではあるので、privateメソッドのような落とし穴に落ちなければ生産性はあまり変わらない
  • 普通のコードを書いているぶんには生産性は変わらない

#NodeToDenoChallenge

• 1/4で終わっている
• 大きなNode.jsプロジェクトをDenoで実行し、実行結果をX上に載せることで応募できる
• ランダム10名に100ドル分のDeno Merchのチケットを渡す
  • Deno Play HoodieとDeno Pocket Teeでちょうど100ドルになる
• グッズで釣ってデバッガーを雇おう！ みたいな感じ
• 成功だけじゃなくて失敗も応募条件としてOKだったので、もっと参加者いるとよかった

__proto__の許容

• --unstable-unsafe-protoで__proto__を許容できるようになった
• 今まではPrototype汚染を防ぐために明示的に消していた
• npm互換性を考えたときに有名プロダクトも使っているので、仕方なくオプションとしてつけた（acorn-nodeを使っているbrowserifyなど）

KV watch

• 結構画期的な機能
• Deno.Kv.watch([["foo"], ["bar"]])と書くことで指定したキーの変更を監視し、バージョンスタンプが変更されるたびにReadableStreamを返す
• リアルタイムアプリケーションを実装するのに楽になるかも
• スケールするのか
  • 例えばクライアントを10K繋いだときに、本当にリアルタイムでできるのか
  • 続報を待ちたい
• 専用でWebSocketサーバーを立てていた人に訴求できるのでは
• そのためだけのDeno Deployを使うというのもありなのでは

I/Oインターフェイスの非推奨化

• skkeletonは内部でdenops.vimを使っている
  • denops.vimは、内部の双方向通信にReader/Writerでプロトコルを書いている
• kuuさんがStream APIに書き換えたら色々と動かなくなってしまった
• Reader/Writerはロック機構があるのでそこら中からReadとかするような実装をすると単純に置き換えられない
• 移行の難易度が上がる
• 内部的に混乱がある
  • Reader/Writerのインターフェイスは非推奨化されるが、read/writeメソッドは消されない
  • Denoエコシステムに深く食い込んでいるため
  • 消すとエコシステムが崩壊する
  • インターフェイスを消すならread/writeメソッドも消すべきでは？ という人もいた
  • ジュニアの人が消すべきと意見があり、シニアは消さないべきという立ち位置のため、消されることはなさそう
• Reader/Writerをラップした何かを作らせないための変更
• 低レベルのプロトコルを実装する場合はReader/Writerがあるほうが良い
• 両方残さないと辻褄が合わない
• std/ioは非推奨になっているが、低レベルのread/writeをサポートする何かとして復活する可能性もありそう
  • 本体には入っていないのでサポートは本体ほど手厚くないけど
  • そういう二段構えにするしかないのかも
• Seekerを使っている場合はそのままで
• こういうときはstd/ioを使いましょう！ というガイドがあると嬉しいかも

ReadableStream.readのminオプション

• tarファイルの圧縮と展開のために必要だった
• 仕様策定がずっと止まっていた
  • 最近になってマージされたので、即座にStream大臣のLeoさんが実装した

decoratorsについて

• hooksが出る前のReactでよく見た記憶
• 今はTypeScriptのdecoratorsがデフォルトになっている
• Deno v1.4でTC39のdecoratorsがデフォルトになる
• プロポーザルの中で最も議論されたものかも

Denoのハンズオンについて

• Denoハンズオンが近々台東区でやるかも

参考資料

上記をまとめる際に眺め、かつ箇条書きの中に含められなかった資料です。
名前だけ掠ってて関係ない資料もあるかと思いますが、まとめる作業の可視化として残しています。
読まなくて大丈夫です。

• kt3k: "久々に Deno に割と大きめの機能を実装した。..." / #times-kt3k
• feat(ext/fetch): allow Deno.HttpClient to be declared with using by magurotuna · Pull Request #21453 · denoland/deno
• feat(lsp): provide quick fixes for specifiers that could be resolved sloppily by dsherret · Pull Request #21506 · denoland/deno
• docs: update help doc for deno fmt --no-semicolons arg by johnspurlock-skymethod · Pull Request #21414 · denoland/deno
• feat(ext/web): add ImageData Web API by jamsinclair · Pull Request #21183 · denoland/deno
• feat(test): add default to --coverage option by kt3k · Pull Request #21510 · denoland/deno
• The Company | Deno
• JavaScriptのプロトタイプ汚染攻撃対策は難しい - Qiita
• Node.jsにおけるプロトタイプ汚染攻撃とは何か - ぼちぼち日記
• denoland/nodetodenochallenge: Take any Node project, run it with Deno, share on Twitter, earn prizes #NodeToDenoChallenge
• Vite (Unstable)
• :bug: Fix always use last callback at wait_async() by kuuote · Pull Request #275 · vim-denops/denops.vim
• refactor: persists connection at skk server client by kuuote · Pull Request #175 · vim-skk/skkeleton