gem_rbs_collection の新しいワークフローの紹介

先日、ある gem の型情報を gem_rbs_collection に投稿したところ、
ワークフローが以前と変わっていることに気づきました。

今回はこの新ワークフローを紹介します。

gem_rbs_collection とは?

gem_rbs_collection は Ruby の型情報を収集しているリポジトリです。
Python の typeshed や TypeScript の DefinitelyTyped に相当します。

RBS では、型情報をいくつかの場所に分けて管理しています。

• Ruby の組み込みクラス、標準ライブラリの型情報
  • rbs gem に収録
• gem の型情報
  • gem 本体に同梱
  • gem_rbs_collection に収録
  • 個々のアプリケーション内で管理
• 個々のアプリケーションの型情報
  • 個々のアプリケーション内で管理

gem_rbs_collection は gem の型情報を収集しています。ActiveRecord や AWS-SDK, Faraday など、著名な gem の型情報も収録されています。

理想としては、gem の型情報は gem のソースコードとセットで管理されることが望ましいです。gem 自体の変更をキャッチアップしやすく、型の不一致が起きづらいというメリットがあります。ただ、現時点では Ruby の型はポピュラーではないため、型情報を扱っている gem はまだ少ないような印象があります。

また、個々のアプリケーション側で型情報を保持する手もありますが、再利用性が低いですし、車輪の再発明をすることになるため、可能な限り誰かが作った型情報はシェアしていきたいですよね。

こうした事情から、様々な gem の型情報が gem_rbs_collection に集約されています。私もこれまでいくつもの gem を gem_rbs_collection に投稿してきました。

これまでのワークフロー

さて、そんな gem_rbs_collection への投稿は、以前は次のようなワークフローで行われてきました。

1. コントリビュータが gem の型情報を作成
2. gem_rbs_collection に PR を送る
3. メンテナがレビュー
4. マージされ、gem_rbs_collection の一部として公開される

PR & レビュー & マージという、よくある OSS の開発フローですね。

しかし、このフローにはメンテナの負担が大きいという問題があったようです。今回のワークフローを変更する PR である Add workflow script for repository management では、メンテナの pocke さんがボトルネックになっていた(なることがあった?)と説明されています。

実際、PR がマージされるのに時間がかかっていた時期がありました。例えば、かつて activerecord: Add ActiveRecord::Base.sum という PR を投稿した際は、マージされるまでに 3ヶ月ほどかかりました。

ボトルネックになっているとは言うものの、OSS の作業はボランティアベースですし、メンテナに過度な負担やプレッシャーがかかるのは望ましくありませんし、私もレビューを急かすつもりはありませんでした。

それに、レビューをすると言っても、メンテナは「型のプロ」であって「gem のプロ」ではないですから、メンテナが把握していない gem の型情報をレビューするというのは難しかったのではないかと考えています。

いずれにせよ、これまでのワークフローは健全ではないということで見直しが行われたようです。

新しいワークフロー

新しいワークフローでは、コントリビュータ自身が PR をマージできるようになっています。そのため、次のようなステップで型情報を登録できます。

1. コントリビュータが gem の型情報を作成
2. gem_rbs_collection に PR を送る
3. GitHub Actions のテストがパスする
4. コントリビュータが GitHub 上で /merge とコメントする
5. GitHub Actions によって PR がマージされる

このワークフローでは、コントリビュータと GitHub Actions だけが登場し、メンテナが間に入ることはありません。型情報の作成からマージまでをコントリビュータひとりで完結できます。

メンテナが間に入らないことで、ボトルネックを解消するという目論見のようです。

型情報を投稿してみる

このワークフローを体験するため、Marcel gem の型情報を作ってみました。Marcel はファイル名やファイルの内容から MIME タイプを判定する gem です。去年お手伝いした Kaigi on Rails の conference-app で利用している gem です (そういえば後編書かなくちゃ…)。

conference-app に型付けしている時期は、ちょうど gem_rbs_collection のマージが滞っていた時期だったため、アプリケーション側で型情報を保持していました。いくつかの gem については gem_rbs_collection に投稿していたのですが、すべてを投稿するパワーが無かったという事情もあります。

Marcel gem の型情報を投稿した PR はこちらです。この記事では、型情報を作る方法については説明を割愛します。興味がある方は gem_rbs_collection の CONTRIBUTING.md を参照してください。

PR を作成すると、GitHub Actions により自動的に PR のマージ手順がコメントされます。

このコメントに従い、/merge というコメントを送信すると、PR が自動的にマージされます。

これでおしまいです。あとは手元で rbs collection update を実行すると、rbs_gem_collection に収録された型情報が取得されます。

だれかにレビューをしてもらえないのは少し不安がありますが、メンテナのみなさんも Marcel gem に詳しいわけではないでしょうし、レビューによる改善はあまり見込めないのかもしれません。文法エラーなどのチェックは GitHub Actions によって CI されているので、完全に壊れたものがマージされる可能性は低いはずです。

まとめ

この記事では gem_rbs_collection の新しいワークフローを紹介しました。

今回の変更によって、コントリビュータが独力で gem_rbs_collection に型情報を投稿できるようになり、メンテナの負担が軽減されました。

型情報がスムーズにマージされることによって、より多くの gem の型情報が gem_rbs_collection に収録されることが期待されます。あなたも手元の型情報を投稿してみてはいかがでしょうか。

なお、本記事を書き上げてから教えてもらったのですが、今週開催される RubyKaigi 2024 の Community-driven RBS repository – RubyKaigi 2024 というトークは、タイトルから推測するにこの内容について触れるのではないかと思います。メンテナの言葉でこの内容を聞きたい場合は、ぜひ pocke さんのトークを聞きに行ってはいかがでしょうか。

※ ネタ被りしてヒヤッとしたのですが、「事前情報を持って登壇を見れたほうが、より理解が深まるのでは」という温かいお言葉を頂いたので、勢いで投稿しますw