Deno STD 安定化の話

class: middle, center

# Deno Standard Library<br />安定化の話

Yoshiya Hinosawa @kt3k

---
## 目次

- なぜ安定化したのか
- どうやって安定化したか
- 安定化でどうなったのか

---

## Yoshiya Hinosawa

- x.com / github - @kt3k
- Deno の中の人。最近は Deno Standard Library と Deno 本体の Node 互換周り担当
- 元々は普通の Web エンジニアをしていました (- 2019)

---

## 安定化以前の Deno STD

- Deno CLI (本体) と同時にリリース
- Deno CLI の patch or minor バージョンが上がるたびに STD マイナーバージョンが1上がる
- 例
  - Deno CLI 1.42.3 -> 1.43.0
  - STD 0.223.0 -> 0.224.0

---

## 安定化以前の Deno STD

- STD 0.223.0 -> 0.224.0 の意味
- SemVer 仕様 4項

> Major version zero (0.y.z) is for initial development. Anything MAY change at any time. The public API SHOULD NOT be considered stable.

0.x 系バージョンではAPI について何も保証されない

---

## 安定化以前の Deno STD

エンタープライズユーザーにインタビューを繰り返していく中で、STD が 0.x.y バージョンであることが、大規模に Deno で開発する事のブロッカーになっているという意見が多くあることが分かってきた

=> STD 安定化を Deno 2 に向けた主目標の一つに設定

---

## 安定化プロセス

- そもそも STD 全体を安定化することは難しいと判断
- Deno STD を 38 のパッケージに分割 (元々のディレクトリ分割をそのまま利用)

--
  - 標準ライブラリが分割されるのはおかしいという意見がコミュニティから多く出てきた

--
  - Deno STD は全体を安定化できるほど成熟していないという理由づけでいなす

---

## 安定化プロセス

パッケージ毎に Release Candidate (RC) Process を設定

- テストとドキュメントについて基準をクリアしていること
  - API が 100% ドキュメントされてること
  - テストは十分に高いカバレッジがあること
- メンテナー (@kt3k @iuioiua) レビューを通ること

以上の基準をクリアすると 1.0.0 RC がリリースされる

---

## 安定化プロセス

- 1.0.0 RC がリリースされてから1ヶ月間はコミュニティレビュー期間
- この期間にコミュニティが変更のリクエストなどを出来る
- RC 期間に出てきたリクエストが全てクリアされると安定化される

---

## 安定化プロセス

- RC プロセスを 34 パッケージに対して今年5月から8月にかけて適用
- 結果 30 パッケージが無事に安定化🎉

--
 - 4パッケージ (io, url, ini, dotenv) についてはプロセス途中で出てきた観点により不安定(unstable)バージョンにとどめる判断に

---
## 安定化したパッケージ

<table align="center" style="font-family: courier; font-size: 27px;">
<tr>
<td>bytes   </td>
<td>collections   </td>
<td>media-types   </td>
</tr>
<tr>
<td>crypto   </td>
<td>encoding   </td>
<td>uuid   </td>
</tr>
<tr>
<td>assert   </td>
<td>data-structures   </td>
<td>html   </td>
</tr>
<tr>
<td>msgpack   </td>
<td>path   </td>
<td>regexp   </td>
</tr>
<tr>
<td>toml   </td>
<td>async   </td>
<td>cli   </td>
</tr>
<tr>
<td>text   </td>
<td>ulid   </td>
<td>expect   </td>
</tr>
<tr>
<td>front-matter   </td>
<td>fs   </td>
<td>json   </td>
</tr>
<tr>
<td>jsonc   </td>
<td>streams   </td>
<td>yaml   </td>
</tr>
<tr>
<td>fmt   </td>
<td>http   </td>
<td>net   </td>
</tr>
<tr>
<td>semver   </td>
<td>testing   </td>
<td>csv   </td>
</tr>
</table>

---
## 安定化したパッケージ

- 古くからある主要パッケージはほぼ全て安定化
  - 例. assert, collections, fs, http, path, testing
- 設定/データ言語系は ini 以外は安定化
  - 例. csv, json, jsonc, msgpack, toml, yaml

---
## 不安定にとどまったパッケージ 8個

- archive
- log
- webgpu
- datetime
- ini
- io
- url
- dotenv

---
## archive

- Tar アーカイブの生成・読み取り処理を提供するパッケージ
- Deno の旧 I/O 形式に依存してしまっており、現在リニューアル中
- リニューアルが間に合わなかったため安定化見送り

---
## log

- Go 言語の log パッケージからインスパイアされて開発されたロギングライブラリ
- JS/TS 用のパッケージとして非常に違和感があるデザインになっているため、メンテナーの判断によって安定化見送り

---
## webgpu

- WebGPU 機能をサポートするライブラリ群を含んだパッケージ
- Deno 本体の WebGPU がまだ不安定機能のため安定化見送り

---
## datetime

- 各種日付処理を含んだパッケージ
- 現在、言語に追加が予定されている Temporal で大部分カバーされる想定のため、安定化せず
- 将来的には deprecate 予定

---
## ini

- ini ファイルの生成と読み取り処理を提供するパッケージ
- ini ファイルには仕様が無く、パーサーは大量にあるが、挙動がバラバラ
- どのパーサーの挙動に寄せるのかという合意が得られなかったため、安定化見送り

---
## io

- Deno の旧 I/O 形式 (Go 言語にインスパイアされた Reader/Writer インターフェースを使うもの) をサポートする各種 Utility を含んだパッケージ
- 旧 I/O 形式は遠い将来には撤廃する意図があるため、安定化するのはおかしいのではないかという疑問が提示され、安定化しない事が決定

---
## url

- URL に対して path 操作が出来るユーティリティ (dirname など) を提供するパッケージ
- 既存の path パッケージの API をオーバーロードすれば十分なのではという意見によって、削除することが決定した。

---
## dotenv

- `.env` ファイルの環境変数への読み込み機能を提供するパッケージ
- 最近 Deno 本体が `--env` という同様の機能を提供し始め、そちらと機能がオーバーラップしている状態
- 上の機能と、STD の dotenv のどちらを推奨するのかの判断が出来なかった (現在も未決) ため安定化を見送り

---
## 安定化後の STD

```
import { assertEquals } from "jsr:@std/assert@1";
```

- バージョン1のパッケージのトップレベルから export されているものは安定 API
- この API は semver に従う。バージョン1の間は破壊的変更は起こらない。

---
## 安定化後の STD

```
import { assertNever }
    from "jsr:@std/assert@1/unstable-never";
```

- 安定化したパッケージの中に不安定 API がある場合がある
  - 安定化プロセス以降に追加された API は一旦不安定 API になるため
- 安定パッケージの中の不安定 API は必ず `unstable-` がついたパスからエクスポートされている

---
class: middle center

安定化した STD を今までより安心して使ってください

ご清聴ありがとうございました