Denoばた会議 Monthly 第17回
2023年3月10日開催。
connpassリンク。
今月のアップデートを追う
Denoのアップデートを追っていくLT。
そのあとの雑談込みでザックリと箇条書き。
package.jsonのサポート
- Denoが
package.jsonを探索するようになった- 概念的には大きな変更
- 最初言ってたことと違うぞ？ とは思われてそう
- まだ試している人は少なそう
- 元から使っていた人はあまり使わなさそう
- 名前の割に、Denoの中が大きく変わったわけではない
- これが入ったことで、Viteプロジェクトが特殊なことをせずとも動くようになった
- 既存のエコシステムとの親和性があがった
- package.jsonの中をゴリゴリ見てるようなプロジェクトで使えるかも
package.jsonのdependenciesをimportできる- Node.jsと同じようなimport文を書くと
npm:URLで解釈される - import_mapの特殊なやつを見ているというように解釈されているので、中身がNodeのようになっているわけではない
requireは引き続きダメ
- Node.jsと同じようなimport文を書くと
deno taskでscriptsを実行できる
std/nodeのDeno本体への組み込み
deno_stdで開発されていたNode.jsのポリフィルがDeno本体に組み込まれた- 今までは標準APIという立ち位置
- 本体に組み込まれたので内部APIも使えるようになった
- この機能を実装したいからRustを直接呼ぶといった、ヤンチャな実装ができるようになった
- TypeScriptで書いてあったところをRustに書き換えるということもしていた
- パフォーマンス的に大事な変更
- cryptoモジュールをRustで書き直すのがDenoチームの流行り
- 今まではcrypto-browserifyでcryptoは実装していた
- crypto-browserifyは完成されているので、この機能がほしいと引き出せばNode.jsのcryptoになっていたので楽だった
- RustのcrateはNode.jsのcryptoに合わせて作られているわけではないので、調整が大変
- ユーザーへの影響
- 起動時の
std/nodeのダウンロードが不要に - ポリフィルの実装にOpなどの仕組みが利用できるように
- esm.shにもサポートが入った (
?target=denonext)?target=denonextは将来的にesm.shのデフォルトになる- Deno DeployのNode互換性が組み込まれたタイミングでフラグが取れるかも
- Deno Deployにも同じ変更を入れようとしてるがまだ入っていない
- 現状ではCLIでしか動かない
- Deno Deployにも久しぶりに大きいアップデートが入りそう
- 起動時の
不安定機能の安定化
- 以下の機能が
--unstableなしで利用できるようになった- Node-API
- Nodeのバイナリ拡張であるNode-API
- 前はN-APIだったが、名前が変わった
- node-sqlite3はNode-APIのC++ラッパーを利用している
- npmパッケージ(
npm:URL)に依存したリモートモジュール- 賛否両論ありそう
- 安定化はRyanさんがゴリ押しで推し進めてる
- 優しい終身の独裁者（BDFL）なので全員一致で進んでいるわけではない
Deno.CommandDeno.runを非推奨化させようとした- 安定化と非推奨が同時にくると影響が大きいので取りやめた
- 次のリリースで非推奨にする方向にした
- Node-API
deno bundleコマンドが非推奨化
その他の話題
Aurae
- コンテナやVM、プロセスなどの実行を管理する分散システムランタイム
- Kubernetesに近いもの
- AuraeScriptというTypeScriptベースのスクリプト言語を搭載
- 内部では
deno_coreが使用されている模様deno_core単体だとimportはできない- モジュールローダーになんやかんやすればimportできる
- 実装してそう
Software Design 2023年3月号
- gorilla0513さんによるDenoのサーバサイド開発に関する記事の連載が開始
- kt3kさんやmagurotunaさんが監修
- 3月号は一番最初
- Denoとは？ という記事
- 多くのDenoにあまり触れていない人に向けたもの
- 3回連載される
- これを書いている途中でNode互換性のリリースがバンバン出たので、Denoのそもそものモチベーションの記述に注意書きが必要な感じになってしまった
Deno Deployの機能追加について
- ここ半年くらい機能が出てない
- 事情がある
- Netlify Edge FunctionがDenoベースなのだが、安定性を向上させる必要性があった
- Deno DeployはNelify Edge Functionに使われている割合が多い
- 安定性向上にDeno Deployチームのリソースがほとんど食われている
- UptimeをモニタリングしてSLA（99.nn%？）を今後設定しようとしている
- ここを直せばあっちに問題が出る、という状態なので急にリクエストが増えた場合にスケーリングの問題がある
- 半年前はスパイクしなくてもなんかおかしい、という時期もあったので進展していると思う
- スパイクがなければ取りこぼしが発生しなくなった
- スパイクが一番大きい問題
- 掃除するアルゴリズムをもっと良くしたい
- 掃除するタイミングで今きているリクエストを捌き切らないと大変
- スパイクが直せればなんとかなるだろう
- GCは更に先
- 機能追加は水面下で進んでる
- データ保存系の機能
- バックエンドはほぼ終わってる
- あとはフロントエンドのボード
- 早く使いたい人はwaitlistにという感じにしたい
- 1〜2ヶ月先に出ます
- データベースに詳しいHeyang Zhouさんが実装している
Rspack
- SWCベースっぽい感じ
- DenoのようにSWCを読み込んでなんやかんやしてる
- webpackのいくつかの課題を解決したもの
- ByteDanceはwebpackゴリゴリで苦労していた
- なのでwebpackとの互換性にはかなり気を遣っているように見える
- Turbopackはwebpack互換をやめた
- webpack互換じゃないとダメでしょ！ という茨の道をあえて選んだプロダクト
- webpackはメタフレームワーク経由で使うことが多いので、新規では採用される機会は少ないかも
- Denoと同じくRustを使っているが、Deno界隈と交わりはなさそう
質問共有コーナー
モジュールローダーのところ本体側にあるモジュールローダーがpublicになっていない理由はあるの？
- そこらへんはあんまり考えてないのでは
- モジュールローダーがないと
importが動かないので、importがないdeno_coreは始めたときに躓く - 一応公式のexampleではローカルのローダーを読み込む方法はあるが、リモートの方法がない
- クレートを使う人としてはありがたい
- あるべきな気がする
- 再利用可能なように提供するか議論されてきていない
- 誰かがこういうふうにローダーを提供すれば、Deno互換なランタイムが作れるというIssueやPRが出れば議論が進むかも
- あんまり使ってない
- Deno互換なimportが動くDenoじゃないランタイムという実例がないので、そういうモチベーションが生まれづらいのかも
- 2020年にモジュールローダーAPIのプロポーザルが出ていた
- Bunが出る前くらいなので、みんな常にブレストモードでIssueが生まれたのかも
- Rustで作ったAPIサーバーで使いたいというシーンがあるかも
- 使いたいNodeの資産というのは？
- フロントで使っているNodeのモジュールがあって、これをバックエンドで流用したい
- コアロジックをRustにしたいけど、Denoを噛ませられるなら噛ませたい
- RustでWASM作ってそれを使うのがいいかもしれないけど……
- Nodeで書かれたものはRustからすれば遅いから、モチベーションとしては高くなりにくそう
- Nodeの資産を解きほぐせないなど理想的ではない状況や、負の遺産を使うための回避策に近い
- 必ずしもNodeの資産をRustで使いたいというわけではない
- 使いたいNodeの資産というのは？
質問代わりの雑談
SWCの作者さんがMSRVをnightlyにあげたいといって物議を醸した
- DenoがSWCをガッツリ使う前は、SWCのmacroがnightlyに依存してた
- Denoからnightlyに依存するのをやめてほしい、と言った記憶
- Rustの安定バージョンだけだと書く量が増えて大変なので、nightlyにしたいというモチベーション
- 「コントリビュートしないユーザーのためにバージョンを固定しないといけないのか？」という疑問も書いていた
- 使っている側からすればやめてほしい案件
- リプライなどでも反対意見が多いけど、どう決定するのか気になるところ
- Deno社のDavidさんもリプライしている
box_patternsというものがnightlyにはある- パターンマッチの中でboxを検知して出し分けるもの
- nightlyで一番ほしいのはこれ、と作者が言っている
box_syntaxというのがremoveされるbox 5とか書いたらBox::new(5)にしてくれる機能box_patternsにも似たような構文は使われているが影響なし
- RocketというWebフレームワークがあったけど、nightlyに依存してた
- 人気が落ちた理由の1つにnightly依存があるかも？
- SWCにはなるべくStableにとどまってほしい
Node.jsにパーミッションや単一実行可能アプリケーション作成が実装されつつあるが、Deno側としてはどういう心境なのか
- 傍観という立場
- Ryanさんは、たまに後追いで追いつかれる状況を懸念している
- DenoがNode.jsの実験台みたいになってしまう懸念
- 逆に言えばDenoは先を走ってNode.jsは後追いする立場なので、Node.jsが真似したのならそれは良い機能なのだという捉え方もある
- DenoのいいところをNode.jsが取り込んでいて、今後が気になる
- Node.jsより先行して便利な機能を入れていけば、コミュニティのシェアも得られるかも？
- Node.js去年の進捗まとめのようなGoogleの人のスライドがあったが、ほとんどDenoで実装済みのものだった
- テストランナーやファイル監視、引数パーサや単一実行可能アプリケーション作成など
- Node.jsの革命期
- コアを小さくしてnpmで補完するような考え方は終わった
- Node.jsの最近の大きな機能実装は、既にDenoにはある
- よく捉えれば、Denoが先行しているランタイムとも言える
- Node.jsが独自進化をしていないというのは、Denoにとっては有利な情報
- あとはユーザーが増えれば……
- Denoは5月にそろそろv2が出る可能性がある
- 誕生日リリースの可能性もある
tsc以外のTypeScript型チェッカーの話（stcとEzno）
- Eznoが最近公開された
- ソースコードなしのアナウンスだけして、ついにものを出してきた
- パーサーは自前っぽい
- SWCを使ってないTypeScript向けツールがあまりないので珍しい
- RSLintがあった
- SWCのコミットは開発者本人の比重が大きい
- stcは議論プロセスなくても大丈夫そう
- Bunは議論プロセスはあったほうがいいだろう
- 大きいコードベースになると、理解してポンッと引き継ぐというのは難しい
- オリジナル作者がいるところで大きい機能を実装しようとして、オリジナル作者と議論を重ねていくことで知識を継承している
- Node.jsは膨大な人がそれぞれの分野に分かれてチームを組み、知識を分割している
- DenoもRyanさんから知識をある程度は引き継いでいる
参考資料
上記をまとめる際に眺め、かつ箇条書きの中に含められなかった資料です。
名前だけ掠ってて関係ない資料もあるかと思いますが、まとめる作業の可視化として残しています。
読まなくて大丈夫です。