現在Qiitaでは graphql-rubyアップデートで引っかかった点(1.8->1.12) - Qiita でも触れた通り、Ruby3.0へのアップデートを進めています。
基本的に自分1人がエイヤエイヤと進めて、ほぼほぼ動く（Rspecは全部通ったが、まだ実際に動かす検証が足りない状態）のものが完成しておりどんなに遅くなっても1月末には出せるだろうという状態です。
そこで、早計ではありますがここに苦労したよという部分を何個か選んで書いてみることにしました。
もしかしたら、今後何かにはまって増えるかもしれません。
1. 破壊的変更に付いていけず放置されたGem対応
若干主旨からは外れそうな気もしますが、一番苦労したのはこれです。
基本的にはDependabotなどにより可能な限り新しい状態を保とうとしていますが、 破壊的変更多すぎ！今は余裕ないから後で！ 放置されてしまうGemや、そもそもDependabotが作るPR数を絞っているとなかなかPRが作られないGemが出てきます（基本的にセキュリティに問題があるGemを優先するので）。
今回のQiitaだと、 graphql-ruby がこれに該当し、使っている部分も多くCHANGELOGもべらぼうに長いため確認にかなりの時間を使ってしまいました。
開発が完全に停止したGemがなかったのが唯一の救いです。
2. rspecのオプションの理解不足による、エラー捜索の難航
基本的に今回のRuby3対応では、まずrspecを通そうというところからスタートするのですが、Rspecではエラーが起きた時、RspecはGemなどで引数エラーが起きた時にGemのトレースをデフォルトでは見れません。
bundle exec rspec -b #(--backtraceでもOK)
で、読むことが実際にはできるのですが、これを知らず（調べようとせず）最初の方は実際にどこで起きてるのか#source_locationなどを使って調べていました。
Gemにあたりがつけば、そのGemがRuby３対応してるか確認して、そのバージョンに上げる対応をする、してないならPRを送るなどの対応を即座に取れるので、こういう細かいオプションは知ってるととても便利です。
3. レビュワーに環境構築手順を教えられない
Rubyはrbenvあたりを使えば簡単にインストールできますが、Gemは数が多いと一発で通らないこともままあります。
そうなると調べてガチャガチャと入るまで試すことになるわけですが、何をしたかログを取ってなかったことで、
「試そうとしたらこのGem入らないんだけど（自分も一発で通らなかったが何をしたか記憶にない）」のような状態が起き、レビュワーに突っ込まれることになります。
しっかりと何をしたら動くのかログを取り、また他のメンバーが環境構築を楽にできるようにするとこまでがアップデートです。
自分の環境とCI動いただけで満足しないようにしましょう（自戒）。
まとめ
この記事では、Ruby3のアプデで詰まったことについてまとめてみました。
- 日々使っているGem（ライブラリ）は可能な限りまめにあげておく
- 使っているツールの細かいオプションは、知ってると開発を助けてくれることがある
- 環境構築時には何をやったかログを取る
このように改善点をまとめると、Ruby3固有のものというよりは、日々の開発にも流用できそうな改善点が多くあります。
実際、Ruby3での変更点は公式がかなりわかりやすくまとめており、自前のコードの対応よりはライブラリの対応で苦戦した、っていう人も多そうです。
特にライブラリ周りは、怠っているといつか今回のRuby3対応のようなタイミングで地雷となり爆発するので、そうならないうちに上げていきましょう。