WinterCGのRuntime Keysとは何か
WhyKまとめ
- WinterCG Runtime Keysはランタイムの識別キーの定義のみを行なう
- 識別キーは利用側で使う
-
package.jsonのexportsにも識別キーは使われているが、これも利用側で使う用と思われる
WhyKLTが採択されたので、ザックリと解釈していたWinterCGのRuntime Keysについて理解を深める。
提案書
議論
参考（になりそうな）資料
WhyKそもそもWinterCGとは何か
複数あるJavaScriptランタイムで標準化Web APIを相互運用できる実装に焦点を当てた、新しいコミュニティグループ。
Deno Land Inc.のLuca Casonatoさんと、Cloudflare, Inc.のJames M Snellさんが二人で話をしていて、それがWinterCGに繋がった、らしい。
WhyKRuntime Keysとは何か
WinterCG (Web-interoperable Runtimes Community Group) が提案している仕様で、様々なJavaScriptランタイム環境を識別するためのキー。
異なるランタイム環境間での互換性と相互運用性を向上させることが目的。ランタイムが識別できることで、開発されたモジュールはそれに適した実装をランタイムに送ることができる。
WhyKWinterCG Runtime Keysの種類
- Alibaba Cloud EdgeRoutine -
edge-routine - Cloudflare workerd -
workerd - Deno -
deno - Lagon Runtime -
lagon - React Native -
react-native - Moddable SDK -
moddable - Netlify Edge Functions -
netlify - Electron -
electron - Node.js -
node - Bun -
bun - React Server Components -
react-server - Vercel Edge Runtime -
edge-light - Fastly Compute@Edge -
fastly - Kiesel -
kiesel - Wasmer Edge -
wasmer
計15個（LagonはVercelに吸収済）
正直ここ見ればOK
WhyK正直カンファレンスまでに全部は調べられないので、カンファレンスで話すことを簡潔にまとめたい
まとめた内容は後日に記事にしたい（忙しいので10月に出せれば万々歳）
話すこと
- WinterCGでランタイムの識別キーとして策定されたものであることの紹介
- 主要なキーの紹介
- 活用事例の紹介（Node.jsを引き合いに出す。Honoは確実に活用してて、Gatsbyも活用しているらしいことを加えるかは検討中）
これで正直50秒は経つと思う
記事にしたいこと
- WinterCG Runtime Keysはどこから取得できるのか（Honoの解読）
- 主要なキーの他に意外なキーがあること（Electronなど）
Runtime Keysの取得処理確認については、以下リポジトリで検証する
WhyKNode.jsのRuntime Keys対応
v20でドキュメントに記載
Node.jsのv18のドキュメントサイトにRuntime Keysについての記述が載っている。 以下のPRで追加された模様。 リリースPRとしてはv20.4.0とv18.18.0に紐づけられている。v18.18.0のほうはバックポートということ？
v20.xのPackage.jsonの読み込み部分と思われる部分では、型定義に明示されていない（わざわざ明示する必要もないと思うが）
WhyK各ランタイムの議論の場
React Native
WhyKHonoで読み解くRuntime Keysの置き場所
現行最新版のHonoで、getRuntimeKeyは以下のように記述されている
直近のNode.jsやDeno、BunやCloudflare Workersはnavigator.userAgentの中に書かれているようで、それをもとに仕様に準拠したRuntime Keyを返している。
また、それ以外はglobalThisを拡張している模様で、Vercel Edge RuntimeやFastifyはv21.1.0以前のNode.jsはそちらから読む必要があるらしい。
Honoの実装を見た所感
WinterCG Runtime Keysは利用者側で使われるもので、各種ランタイムから統一された提供がされているわけではない？
WhyKDenoのユーザーグループにも質問してみるけど、ちょっと領分外だから回答こないかも
もうちょっとプロポーザル自体を見直したほうが良い……
WhyK提案書読み下し
1. Introduction
This proposal defines a list of keys that represent various runtime environments.
These keys can be used in a variety of ways, and should be considered a reliable representation of the given runtime.
For example, they may be used in a project configuration file to indicate the given project supports the specified runtime.
This specification does not detail how the keys can be used; that is left up to community developed tools.
The point of this proposal is to only define what the keys are in order to prevent conflicts, and provide users a reliable list of platforms they can build tooling around.
Inclusion in this registry does not imply that the specified runtime is conformant with the WinterCG Minimum Common API.
Inclusing in this registry does not imply endorsement of any kind.
この提案は、様々なランタイム環境を表すキーのリストを定義する。
これらのキーはさまざまな方法で使用することができ、指定されたランタイムの信頼できる表現とみなされるべきである。
例えば、指定されたプロジェクトが指定されたランタイムをサポートしていることを示すために、プロジェクト設定ファイルで使用することができる。
この仕様では、キーの使用方法について詳述しない。
この提案のポイントは、競合を防ぐために、キーが何であるかだけを定義し、ユーザーがツールを構築できるプラットフォームの信頼できるリストを提供することである。
このレジストリに含まれることは、指定されたランタイムが WinterCG Minimum Common API に適合していることを意味するものではない。
このレジストリに含まれることは、いかなる種類の推奨を意味するものでもありません。
これを見る限りは識別キーを定義しているだけで、利用方法については言及していない。
よって、各ランタイムが必ず識別キーを提供しないといけない、というわけではない。
1.1. Example Usage
One example of how these keys may be used (remember, this proposal does not specify how the keys are to be used) is within package.json files for projects hosted on npm.
The following package.json file demonstrates a library that exports separate outputs for Node.js and Deno, as well as specifies which versions of each runtime it supports.
これらのキーがどのように使用されるかの一例として（この提案では、キーの使用方法は指定されていないことを忘れないでほしい）、npmでホストされているプロジェクトのpackage.jsonファイルがある。
以下のpackage.jsonファイルは、Node.jsとDeno用に別々の出力をエクスポートし、それぞれのランタイムのどのバージョンをサポートするかを指定するライブラリを示している。
package.jsonが引き合いに出されているが、これが見つからない……。
WhyK識別キーの定義だけで、それ以外の拘束力は持たない仕様提案書なのかも。
Honoなどの利用側が定義する際の助けになる仕様ということ？