21はじめてのOSSコントリビュートJavaScriptFirebaseOSSFirebaseExtensionsはじめに「「「OSS貢献」」」がなにかとても偉大ですげぇことだと思っていた頃が自分にはありました。筆者は新卒2年目のフリーランスWebエンジニアですが、ちょくちょくとJavaScript(TypeScript)のライブラリに軽微な修正PRを送るようになったのは、まだほんの最近のことです。この記事では、筆者が執筆時点(2019/12)で実際に送っているPRを参考に、OSS貢献未経験者向けに流れをざっくり書きます。※なお筆者は主にWebの開発者なので、業界が違えば様々なやり方や慣習が異なることはあらかじめ断っておきます。いうプラグインにバグを見つけたので、修正しました。Extensionsについては、こちらのQiita記事などを読むと雰囲気が分かるかと思います。アップロードされた画像を自動で指定したサイズに変換してくれる頼もしい拡張機能ですが、SDKを使ってアップロードする時に、対象referece名に拡張子がない場合、ファイル名が消えてしまう現象を発見しました。(下図やPR参照)ちなみに、Qiitaにもこの現象を報告した記事がありました。この現象に初めて遭遇した時、文字列の操作に失敗している類のあるあるバグだなと勘付いたのでソースコードを眺めたところ、すぐに原因がわかりました。PRの確認いくら修正が簡単とはいっても、バグを発見した時にまず初めにするべきことは、関連するissueやPRが既に存在しないかどうか確認することです。プロジェクトによっては、リリースされている最新版やmasterブランチでは未対応でも、次期リリースやnextブランチでは既に対応済みだったりすることもよくあります。マージされていないopenなPRが上がっていたり、過去に同じバグに対して送られたPRがなんらかの事情でcloseされていることもあるでしょう。blameをうまく使いながら、現在のコードがなぜ今その状態であるのかを知ることが、まず1番初めにしなければならない作業です。本記事で扱っているケースの場合は、関連するissueはいくつか上がっていたもののそれらしい修正PRはまだ誰も着手していないようだったので、自分で着手することにしました。リポジトリをforkするこれは当たり前の話ですが、自分がcollaboratorではないリポジトリにpushすることはできないので、まずは自分のアカウントにリポジトリをforkします。cloneしましょう。バグの再現とテストの作成まずは、バグが確実に起きるテストケースを書いて、そのテストが確実に通らないことを確認します。Extensionsをローカル環境で走らせる方法がない?為に、この手順をスキップせざるを得ませんでした。代わりに、PRの概要に発生する条件を書いてスクリーンショットを添付しました。いえ、自分が追加した部分のユニットテストはもちろん書きます。壊れたテストがあれば、あとはそれを動くするようにするだけです。この際に注意する点として、なるべくレビュワーの負担を抑えられるようにする為に修正は可能な限り小範囲に留め、またそのプロジェクトで使われているフレームワークや書き方をなるべく踏襲するようにすると、より早くマージしてもらえることでしょう。対象動作環境についてまた、そのコードが動作を期待されている環境についても、確認が必要です。Node.jsのプロジェクトであれば、大体以下のような場所を確認すると、おおまかな動作環境は確認できます。Functionsなどの場合は、ランタイムで動作がサポートされているNodeのバージョンが公式docsに載っていたりするので、その辺りを確認するのも良いでしょう。https://firebase.google.com/docs/functions/manage-functions#set_nodejs_versionコミットについてgitのコミットについては少し注意が必要です。Electronの場合は、コミットメッセージの書き方についてガイドラインに書いてあります。logを見て大体雰囲気を合わせたコミットをすれば良いかと思います。ビルド生成物について通常はあまりないパターンですが、本記事の例の場合は、ビルド時の生成物をgit管理しているプロジェクトだったので、ビルド後にそれらもコミットしました。PRを送る修正が完了したら、自分のリポジトリにpushし、本家にプルリクエストを送ります。プルリクエストのテンプレートがあるようなプロジェクトであれば、それに沿ってプルリクエストの内容を書きましょう。この時、実際に発生したバグのissueのurlを貼ったり、適切なラベルをつけることは大切です。PRなどにも、自分の作成したPRのリンクを貼り付けていけば、忙しいメンテナーの目に止まりやすくなり、スムーズにマージしてもらえるかもしれません。コミュニケーションはなるべくフレンドリーにすることを心がけましょう。これは個人的な意見ですが、自分の書いたコードに不備があったとしても、粗雑な言葉遣いで「壊れてから直してやったよ!」みたいに言われていい気がする人はいないでしょう。手っ取り早い話で言えば、絵文字とかを使うと文が明るくなりますし、英語の婉曲表現を使うと穏やかに伝えられます。it.(PRを作りました。it?(頑張って直してみました。見てみてくださいませんか?)最後に英語に苦手意識があったり、OSSを遠い存在に感じる人もいるかもしれません。筆者も色々なライブラリを読むようになってから気づいたのですが、意外なことに、有名なライブラリでもそんなに綺麗ではない実装がされていたりテストが不十分だったりと、猫の手も借りたいような状況のことはよくあります。Checkerを使えば、英単語の綴り間違いを簡単に修正できるので便利です。自分への戒めなんですが、みんな「〇〇のライブラリは壊れている」とか「〇〇は使いにくい」とか言ってしまいがちです。ハマりどころを回避する記事を書く時間があるなら、OSSなら自分でそれを直してしまった方がメチャクチャかっこいいと思います。(※Electronより引用)です。雄一@Yuichi_Yogo音楽家・エンジニア。用いたアルゴリズム構築事業を推進し、企業のAI活用を支援しているベンチャー企業です。2つの事業に関する先進技術の研究・開発も行っています。upLoginユーザーは見つかりませんでした。