Denoばた会議 Monthly 第23回
2023年10月13日開催。
connpassリンク。
今月のアップデートを追う
Denoのアップデートを追っていくLT。
そのあとの雑談込みでザックリと箇条書き。
deno jupyter
deno jupyter --unstable --installでDenoカーネルをインストールできるjupyter console --kernel denoでJupyter Consoleと連携可能- Jupyterは機械学習を使っている人がやっているイメージ
- ビジュアライズするのに便利らしい
- Jupyter Notebookよりはこちらのほうがハードルが低いかも
- Denoのカーネルを通してTypeScriptを評価する
- REPLと違ってグラフィカルになる
- Consoleだとわかりづらいけど、Notebookだとわかりやすいかも
- Consoleだとコンソール上に表示されるので、REPLとあまり変わりない
- 評価された内容は、確か保存される
- めちゃくちゃ長い拡張子に保存される
- REPLしたのを評価内容を長い拡張子のファイルにぶち込んでおける
- D3.jsをDenoで落としてグラフを描くことができる
- 用例ではビジュアライズにnodejs-polarsがよく使われている
- これで上手いことデータ分析がビジュアライズされている
- Jupyter側の人が開発に参加してくれている
- これが使えることがJupyter側の人からすると嬉しいらしい
- かなり協業している
- Jupyter側から働きかけがあったわけではない
- Bartekさんが「Jupyterとの連携はいいはずだ」という勘で発案した
- Bartekさん一人でやっていたら、Jupyterの人たちが入ってきて色々とやり取りが生まれた
- JavaScriptで機械学習をしたいというモチベーションがあった
- 実は今回で実装は2回目
- 1回目もBartekさんがやっていたけど、特化した機能が言語ランタイムにあるべきではないという理由でCloseさせていた
- Ryanさんは結構ネガティブだった
- 特別なアプリケーションに特化したものが、言語ランタイムに入っているのはおかしいという意見
- これいいね、とはRyanさんは一言も言っておらず、Bartekさんがやっているのを横で渋い顔をしながら見ていた
- Bartekさんがゴリ押しした格好
- もしかしたら、Jupyterのスタートアップと連携しているところを見て考えを改めたのかも？
- 尖った機能を言語ランタイムに入れると、当然ながら言語ランタイムとして尖ってしまう
- それが変だ、というRyanさんの言はおかしくない
- ただ、入れたら喜ぶ人がいた
- KVが入っていたり、Denoはそもそも言語ランタイムとして特殊
- 特殊なものを取り入れてウケるというのが方程式化している感じがある
- 言語ランタイムとして、今まで入れてなかったものを取り込んでいくのが特色になるかも？
- 特殊すぎるのも諸刃の剣なので、塩梅は難しい
- 特殊な機能を入れたことで、それにしか関係ないIssueが乱立してコアメンテナのリソースが割かれてしまうことをRyanさんは懸念していた
- 現状はBartekさんしか直せない
- Jupyterとのやり取りは何らかのプロトコルなはずで、そこがそうそう変わることはないだろうから、なんとかなるかも？
TAPレポーター (deno test --reporter=tap)
npm:tap-nyanなど、TAPレポーターを実行できるnpm:tap-nyanだと猫に置き換わる- tapはdotよりは情報量あるけどシンプル
- それを入力にしてアスキーアートに置き換えるには結構簡単にできるのでは？
- Mochaはnyanをビルトインで持ってる
-_-_-_-_-__,------,
-_-_-_-_-__| /\\_/\\
-_-_-_-_-_~|_( ^ .^)
-_-_-_-_-_ "" ""
deno lspでnpm:の入力補完がサポート
npm:jsdom@22.1.0のように、バージョンの入力補完まで行なう- 外部委託のNayeemさんが実装してくれた
- かなり長いコントリビュータ
- すごく頭がいい方
- 実装力や仕様理解力はすごくある
- LSPのIssueが溜まってて、そこが不満になってた
- Nayeemさんに相談して、LSP専任のコントリビュータになってもらった
- Nayeemさんで事足りたため、採用サイトでのLSPエンジニアの募集は終わっていた
- より広い範囲のソフトウェアエンジニアの募集に変わっている
- これからのLSPの改善にご期待ください
TypeScript v5.2
- TypeScript限定だが、
usingが利用できる - V8でまだ対応されてないので、TypeScriptじゃないと動かない（トランスパイルで動作する）
- リソース管理がやりやすくなるやつ
- 変数を宣言できるようになり、
[Symbol.dispose]のやつが呼ばれますよ〜、って感じ - Javaにもtry-with-resourcesという似たようなやつがある
- Pythonにwithという似たようなものがある
- JavaやPythonはネストが一つ増えるので、
usingのほうが便利そう usingで宣言された変数は再代入できない- フロントエンドの読み込みインジケータ（fetchを挟み込んでfinallryで止めて）をこれで簡単にできそう
- Go言語だとdefer文というのがあるけど、これは関数を抜けたあとに実行するものを先に書くやつ
- Zigでもdefer文があって、これはGoと似ててスコープ（for文など）を抜けたときに実行するものを先に書く
- Zigにはerrdeferというのもあり、関数の返り値にResult型のような返し方ができ、ResultのErrorのときのみに発火できる
- メモリアロケーションしたときにメモリ領域の開放をしたかったら、errdeferで開放できるというのができる
- スコープの抜け方が正常かどうか、というのはJavaScriptでもいけそう
errdisposeみたいなthrowで抜けたときのみ発火、というのはいけそうでは？
Import Attributesが実装
import ... with { type: "json" }の形式で記述する- 前身であるImport Assertionsは、今後サポートが廃止される予定
- Assertは違うとなって2に降格してAttributesにして3に昇格してた気がする
- Assertもしばらくはサポート
- V8にはAssert入ってるので動いちゃう、いつ消えるかは不明
- Assertはレガシーという扱いになって残す残さないの話になったが、残さないに倒れた
ロックファイル v3
- リダイレクト元とリダイレクト先のURLの組み合わせが管理されるように改善
- 恐らくは後述の
jsr:URLを念頭に置いた対応だと思われる - 意図したバージョンを再現できない問題を解決するために、組み合わせ管理が入った（再現性が高まる）
- esm.shの影響で怒られることが減るかも
- バージョンなしのesm.shのURLとリダイレクト先のバージョン付きURLが記載される感じ
実験的なパッケージマネージャ (jsr:URL)
npm:のように、独自のパッケージレジストリからサードパーティモジュールを引っ張ってくる仕組み- パッケージレジストリがまだ公開されていないため、現状は利用できない
- SemVerの解決をパッケージレジストリとランタイムで合わせて解決する
- インテグレーションテストなどDeno各所で
jsr:は見受けられる - 実装上のインストールの流れ
@foo/somepkgのmeta.jsonを読みに行く- バージョン一覧を探し、要求されたものと一致するものを探し出す
- インストール
- テストファイルを読むと実装が掴みやすいと思う
- Deno社内だとレジストリのStg環境があって、それと
jsr:が紐づいている deno.land/xとはまた違ったレジストリから読みに行っている- 2～3週間前まで積極的にやっていたけど、迷いが生じてきているので開発ストップ中
- 合わせて
jsr:の開発も止まってる - Deno Offsiteで何らかの進展があると思いたい……
- 今はどうなるかわからんという状態
- 合わせて
- jsrはJavaScript Registoryの略で、
jsr:をすべてのJavaScriptランタイムで使えるようにするという展望が話されている- jsrにpublishすればDenoでもNodeでも使えるようにしたい
- ライブラリ作者から両方サポートするのは難しすぎるという苦情があるが、これで解決できるという想定
- Ryanさんが悩み中で、よく理由付けが与えられないまま「レジストリ開発止めて」という話になった
- HTTPインポートや
npm:は「まぁ意味はわかるな」っていうのがあったけど、jsr:は完全独自なので受け入れられるのか？ という懸念もある - 本家Discordはネガティブなリアクションばかり
- ほんとにどうなるんでしょうね……
- どうなるかわからないものが作られている、というのがまた面白い
- Node.jsは分業体制という仕組み上、尖ったものが出しづらい
- 謎のチャレンジができるのがDenoの強みなのかも？
その他の話題
deno_std v1について
- v1リリースに向けて整理が行われている
- kt3kさんが取りまとめている
- Issueでdeno_stdの依存関係グラフを作って安定化してもいいやつの仕分けをしている
- 白い二重丸で囲まれているものは安定化準備完了
- 灰色のものは廃止予定
- 黄色はunstableとして破壊的変更をしながら安定化を目指す
std/collectionは元々Lodashの代替くらいのノリだったけど、他のモジュール実装するのに使う関係でアルゴリズムを実装したツリー構造が入っていた- 「これここにあっていいの？ 毛色違くない？」ということで、とりあえず
unstable/に入った - Rustはstdにあるぞ！ っていう意見もあるので、シレッと復活するかも
- 「これここにあっていいの？ 毛色違くない？」ということで、とりあえず
std/cryptoにはkeychainというのがあるけど、これをstdに出すのはしっくりこないのでunstable/に入ったstd/streamの中にあるGo言語ベースの機能が非推奨- これからはWeb Stream APIでいきます
- deno_stdはkt3kさん任せになってる
- deno_stdに一番関わっているため
- 色々と調べまくりながらやっている
- これ本当にやっていいの？ って調べまくったら「やったらマズいな」というのがあった
- Reader/WriterベースのReaderSyncやWriterSyncがあるけど、これは勢いで非推奨にしてた
- ただこれ、Stream APIだとできない
- 同期的にやるという需要があるのか謎い
- 細かいこと言うとできること減っちゃってるのでマズい、けど今はやっちゃってる
- 残すの？ って言ったら残せないんでやっちゃえ！
- Web Specを追っていくと、Origin Private File System（OPFS）が新しく策定したものの中に存在している模様
- 多分
[FileSystemSyncAccessHandle](https://fs.spec.whatwg.org/#filesystemsyncaccesshandle)？ - Streamじゃないんだけど面倒なインターフェースでReader/Writerみたいなの実装してるっぽい
- OPFSをまるっと引っ張ってこないと使えないので、使えるのは先になりそう
- 多分
- Deno.Seekerというシーク処理インターフェースがあるんだけど、これもStreamだとできない
- Deno.seekメソッドは残ってるのでStreamの途中でシーク処理読んじゃえばいける
- ReadableStreamらしい実装ではない
- OPFSの奥の方にSeek APIが潜んでいるらしいので、必死こいて掘り起こせば近い将来Web標準でのシーク処理っていうのもいけるかも……？
- だいたいのI/OはReadableStreamで問題ない
- エッジケースでなにか問題が出てくるかもしれないけど、Denoはそういうもんという理解でお願いします
Fresh Partials
- SPAのようなクライアントナビゲーションを実現する
f-から始まるのはFreshが独自に実装している属性- リンクを保持するコンテナ要素に
f-client-nav属性を設定しておくと、Partialsを有効化できる。Partialsを有効化しておくと、f-client-nav配下のリンクのクリック時にリロードが発生せず、<Partial>コンポーネントでラップされた領域のみが更新される。 - アンカー要素に
f-partialを設定すると、表記上はhrefに遷移するがデータはf-partialのパスから取得する - 無駄なHTMLがなくなり最適化できる
- Partialsを使わない場合は全体をSSRするけど、Partialsを使うと部分的に再レンダリングする
- こういうフレームワーク今までなかったかも
- 懐かしいAjaxの匂いがしつつ、それがメタフレームワークに取り込まれているのが面白い
- オプショナルで入ったのは面白い
- 今までの使用感は残しつつ、SPA感も取り込んだ
- SPA遷移がないから微妙、と遠ざけていた人にもリーチできそう
- htmxやHotwireとよく似ている
- htmxに影響を受けたことをPRで明言している
- Partialsは前後に足すとかやってるけど、htmxなどと使用感は一緒
- View Transitions APIが生えるので、無理やりSPAにしなくても差分を取り込んでView Transitions APIを噛ませればよいのでは
- MPAだと実験フラグをChromeで建てないといけないけど、Partialsのような部分的差し替えならすぐ試せる
- Astroがv2.9でView Transitionsに実験的に対応したが、それに触発されてFreshでも対応PRが出ている
- 選択的に動的なSPAライクな動きができることが嬉しい
- SPAだとフォーム機能でPOSTしたいのにfetchしないといけないけど、これなら両得な感じがする
- Astroはドキュメント系っぽいので、Freshみたいなアプリケーション系に入るのは嬉しい
- Freshがそういう系では初めてなのでは
- 選べるというのはメチャクチャ強いと思う
Deno Queuesのアナウンス
- Deno v1.34.3でDeno KVに実装されたキュー機能が正式にアナウンス
- 公式からアナウンス記事も出ている
- キューイングがDeno Deployでできるようになった
- 予約やバッチ処理などができる
- AWS SQSでしたいことがDeno Deployでできます！
- タスクキューをガリガリ実装したことがないので利用感の予想はできてないけど、かなり便利
- Deno Deployに完結したサービス開発がやりやすくなってきている
- 定期的に動くBotも作れるかも
WebGPU APIの再導入について
- Deno v1.32で一時的に削除されていた
- 再導入のPRが作成されている
- まだドラフト段階だが、再びWebGPU APIが導入される可能性はありそう
- v1.32で削除した原因は、3ミリ秒のオーバーヘッドがあったから
- 色んなことを遅延させて、WebGPUを使うタイミングで動くようにひたすら調整した
- 1ミリ秒までオーバーヘッドが削減されたので再導入が始まった
- まぁ1ミリ秒でも長く感じると思うけど……
- 何かしらの初期化が走っていて、それで1ミリ秒のオーバーヘッドが出てしまう
- ビルドに30分くらいかかるので、再導入作業はかなりストレスフルだった模様
[ext/webgpu/02_surface.js](https://github.com/crowlKats/deno/blob/webgpu/ext/webgpu/02_surface.js)に初期化系がまとまっている- これとJupyter Notebookを掛け合わせたサンプルを作ろうとしているらしい
- よりビジュアライズになるかも
Deno社メンバーなどの日本前日入り
- 早めに日本入りしてる人が数名（lucaさんやNicolòさんなど）
- Nicolòさんはさっきコワーキングスペースで一緒に作業してた
- Leoさんも一緒にコワーキングスペースで話していた
- NicolòさんからBabelステッカーいっぱいもらった
- JS Conf JPか、無理そうならDeno Festで配りたい
質問共有コーナー
deno.json(c)ってnpm:対応するんですか？
- Issue立ててもらえれば話が進むかも
- 立てました
Terraformのプロバイダの話は触れました？
- シレッとDeno Terraform Providerがリリースされた
- terraform-deploy-providerがあったけど、メンテされてなかった
- イベントで「弊社で使いたいんですけどプロバイダ作ってくれません？」という直談判もあった
- Vercelと同じような体験は提供したいよね、という話は出てて、参考にしている
- CDがあってmainブランチに更新があったらcheckoutして色々用意して、という感じ
- 使い方としてはデプロイのパスを指定して、ファイルをアップロードしてくれるくん（deployctlみたいな）
参考資料
上記をまとめる際に眺め、かつ箇条書きの中に含められなかった資料です。
名前だけ掠ってて関係ない資料もあるかと思いますが、まとめる作業の可視化として残しています。
読まなくて大丈夫です。
- Rename from "assertions" to "attributes" by nicolo-ribaudo · Pull Request #134 · tc39/proposal-import-attributes
- try-using文を用いるJavaScriptの超モダンな“リソース管理” - Qiita
- A Tour of Go
- tc39/proposal-explicit-resource-management: ECMAScript Explicit Resource Management
- 5分でざっと理解するZig言語
- Zig の文書読んで所感を記す - Qiita
- htmxを使ってみる
- Fresh 1.5: Partials, client side navigation and more
- /streams/mod.ts | std@0.204.0 | Deno
- Origin Private File Systemを使ってブラウザ上でファイルを高速に操作しよう