LEFログ:学習記録ノート

leflog: 学習の記録をどんどんアップしていきます

【初コントリビュート】初めてOSS活動をおこなって得た知見、gem 'devise-i18n'を使う上で注意すべきポイント

こんにちは。LEF(レフ)と申す者です。

今回は、RailsのgemにPull Requestを投げて承認され、貢献(コントリビューション)できたことについて書いていきたいと思います。

また、そこで得た知見についてもまとめてみたいと思います。

gem 'devise-i18n'の不具合を見つけて改善案をPull Requestで送りました

自分は最近Railsの学習をしているのですが、gem 'devise-i18n'を使う際に、ちょっとだけ困ったことがありました。

具体的には、rails g devise:i18n:views userのようにスコープを指定してビューを作成したときの挙動が不完全なものになっていました。

例えばapp/views/users/passwords/edit.html.erbなどのファイルにおいて、

<%= render "devise/shared/error_messages", resource: resource %>

というコードが生成されます。

しかし、gem 'devise'rails g devise:views userで試したところ、

<%= render "users/shared/error_messages", resource: resource %>

というコードが生成されます。本来であれば、こちらのコードのほうが正しいはずです。
(スコープ指定でビューを作成したら、deviseというディレクトリは存在しないため)

つまり、rails g devise:i18n:views userをおこなうと、相対パスの記述が修正されないまま、スコープ指定のビューが生成されてしまいます。

そのため、viewsディレクトリのファイルでdeviseになっている部分をひとつひとつ書き換えていく必要がありました。

ただし、ここで注意すべきポイントがあって、一括置換することはできません。

例えば_links.html.erbにおいて、

<%- if devise_mapping.registerable? && controller_name != 'registrations' %>

となっている場所のdeviseについては、usersに置き換えてはいけません

そのため、viewsディレクトリ以下の14個のファイルを一つ一つ目視で確認しながら書き換える必要がありました。

この状態だととても不便です。
deviseはセキュリティに関する大切なgemなので、下手に書き換えるとリスクがありそうな気もしました。

自分の所属している学習コミュニティ(Fjord Boot Camp)で質問したところ、maedanaさんから原因となっているコードを教えて頂きました。

ものすごく簡単に説明しますと、gem 'devise'の更新内容にgem 'devise-i18n'が追いついていないため生じてしまっている問題でした。

該当箇所をほんのちょっとだけ修正すれば改善する問題であったため、Pull Requestを投げてみました。

以下のリンクが、実際に自分が作ってみたPull Requestです。

Problem solved with relative paths not changing when creating Scoped view. by lef237 · Pull Request #318 · tigrish/devise-i18n · GitHub

github.com

リンク先のPull Requestを送った画面

その結果、無事に承認されて、コントリビューションすることができました。

初めてOSS活動をして得た知見

OSS活動」と言うと仰々しい感じがしますが、「GitHubで公開されているコードの改善案を送ってみる活動」と言い換えてみると、もっと気楽に取り組める気がします。

ちょっとしたコードの修正なら、身構えなくても簡単にすることができます。

今回のOSS活動も、自分の中にある「ちょっと不便だし改善されるといいな」という気持ちと、「今までOSS活動したことがないし、明らかな不具合なのに誰も指摘していないし、ファーストペンギンになってちょっくらやってみよう🐧」という好奇心から行動に移しました。

上記のgemの不具合に関して、2年前にもissueとして投げられていたようですが、その際は対応していなかったみたいです。

Wrong scoped views generation? · Issue #278 · tigrish/devise-i18n · GitHub

つまり、「issueとして不具合を報告するより、コードを修正してPull Requestを送ったほうが貢献しやすい」という知見を導くことが出来ます。

今回、初めて外国の方に英語でPull Requestを送ったため、少し緊張しましたが、DeepL翻訳を使ったおかげで、そこまで時間は掛かりませんでした。再翻訳したり、Google翻訳でも試してみて、問題なく意味が通じるかも確認しました。

OSS活動でいちばん大切なことは、やはり「原因を特定すること」だと思います。

gem 'devise'のコードとgem 'devise-i18n'のコードを見比べることで、原因とその改善策を提示することができました。
もし、maedanaさんに該当箇所のコードを教えて頂けなければ、自分では原因を突き止められなかったと思います。ありがとうございます。

自分ひとりで素早く原因を特定できるように、コードを読み書きする能力を高めていきたいと思います。

上記の内容をまとめてみますと

  • gemを使っていて困ったことがあったら、色々挙動を試してみて不具合の詳細を特定する。
  • GitHubで公開されている元のコードを読んでみる。正しいコードと比較してみる。
  • プログラミング能力を上げることで、原因を突き止めやすくなる。改善案も浮かびやすくなる。
  • issueとして問題(不具合)を提示するよりも、自分でPull Requestを出してコードの改善案を提出したほうが貢献しやすい。
  • 翻訳ソフトの発達により、英語でメッセージを送るのは簡単。
  • ちょっとした不具合を改善するだけでも、OSS活動になる。

参考にした記事と、ymlファイルについて

Pull Requestを送るにあたって、参考にした記事をご紹介します

OSS初心者がRailsにプルリクエストを送ってマージされるまでの一部始終 - Qiita

【超図解】OSSにPull Requestを出す時の備忘録 - Qiita

両者ともシンプルにまとまっていて、とても分かりやすかったです。

自分の承認された改善案では対応できなかった点もあります。
それはymlファイル周りの修正です。

【Rails】devise-i18nでscopedなビューを翻訳するワザ - Qiita

ymlファイルについては、この記事を読んでいただければ簡単に対応できると思います。