はじめに
Next.js を使ったことがある人はたくさんいると思いますが、 コントリビュートしたことがある人は少ないのではないでしょうか？
Next.js は Vercel がメンテしてくれていますが、 OSS なのでコントリビューションできます。
この記事では、 Next.js に PR がマージされるまでに僕がやったことを紹介します。 実際の修正内容は詳しく述べません。 修正が取り込まれるまでの流れを紹介し、 「全然大したことしてないじゃん、僕でもできそう」と思ってもらえることがゴールです。
Next.js
またこの記事は Recruit Advent Calendar 2021 の 3 日目の記事です。
明日は MaxMEllon さんの記事の予定です。
TL;DR
GitHub のコントリビューションガイドか YouTube を見てコントリビューションしてみましょう！
僕の記事を読むより公式の記事や動画の方が正しいと思います。
僕が具体的にどのようにコントリビューションしたか少しでも興味がある方は本編をご覧ください。
本編
前提: この記事を書こうと思ったきっかけ
11/27 の JSConf に登壇しました。
その際に @__sosukesuzuki さんの基調講演を聞き、 OSS の貢献の重要性を再認識させられたからです。
JavaScript エコシステムを維持する OSS の努力と課題 - Speaker Deck
発表はおそらく YouTube に上がると思うので、配信されたらぜひ見てみてください。 きっかけはこの発表だけではないですが、一つのきっかけになったのは確かです。
つい先日僕が Next.js に出した小さい修正 PR がマージされました。 ログ出力のフォーマットを変更する PR です。
fix amp validator message format by ka2jun8 · Pull Request #31018 · vercel/next.js · GitHub
特に大した内容ではないので、こういう小さなところから コントリビューションできることを示す良い題材かなと思いました。
まず Issue から
普段業務で Next.js を使って開発を行なっています。 Next.js はアップデートが多く機能追加も多いのでありがたいのですが、 アップデートされた変更によってバグが発生することもあります。
今回僕が出した Issue の場合は、 Next.js ログ出力がなぜか縦書きになってしまうというものでした。
AMP Validator error logs are shown vertically · Issue #31012 · vercel/next.js · GitHub
OSS のバグに出会った際に僕が行うことは、おおよそ以下のような流れです。
- 問題に直面したら既存の Issue を探す。
- Issue がなければ原因を自分なりに調査する。
- OSS 側に問題がありそうだと判断する。
- 実際に Issue を出す。
バグは大抵自分が書いたコードのせいで発生します。 しかし今回のケースでは Next.js 側が出力しているログ出力なので、Next.js 側を怪しみました。
まずこういう場合は既存の Issue を探して同じことに困っている人がいないか確認するようにしています。 今回同じような問題を報告している Issue を見つけることはできませんでした。
この時点で Issue をあげる人もいると思いますが、 僕の場合は Next.js のソースコードを読み該当のエラーがなぜ起きるのかを確認するようにしています。 もし自分のコードや環境が問題だった場合に、 OSS のメンテナに余計な負荷をかけたくないからです。
特に今回は Next.js のアップデート後に発生していたので、 Next.js が一つ前のバージョンから何を変えたのか確認しました。
今回のアップデートで、問題が起きた該当のログ出力機能に変更が加えられていることがわかりました。
https://github.com/vercel/next.js/pull/29753/files
Next.js の examples にある最小構成でも発生することを確認しました。
next.js/examples/amp-first at canary · vercel/next.js · GitHub
前のバージョンでは発生しないことを再度確認し、 この辺りで Next.js 側に Issue を立てることにします。
ちなみに Issue を見てもらえればわかると思いますが、 英語はほぼ 2〜3 行しか書いていません。
伝わればヨシ！の精神です。 僕が Issue をあげる場合は、英語の代わりにスクリーンショットや実際のコードを貼ることが多いです。
Issue を出すだけでも、一つのコントリビューションです。 ちゃんと GitHub に草も生えます。
コードの修正
ここからは、 PR を出すことを目標にします。 実際にコードを修正します。
vercel/next.js のコードを clone し、 基本的には contributing.md の通りに進めます。
僕の今回のバグの場合は、該当行に余計な変更が入っていることが問題だったので、 上述した前のバージョンとアップデート後の変更箇所のマージを行いました。
https://github.com/vercel/next.js/pull/31018/commits/34b589febdd3936ac71bd730e22c95c8467de2f9
大した修正ではないことがわかってもらえると思います。
動作確認
書き換えたコードを含む Next をローカルでリビルドします。
ビルドに通ったら、 examples にある最小構成で確認します。
以下のように examples 配下のフォルダを指定すると、ローカルでビルドした Next.js で確認することができます。
yarn next ./examples/amp-first/
便利ですね！
テストの追加
僕は上の時点ではやる気持ちが抑えきれず PR を出してしまいましたが、 テストを追加するのがマナーです。
まずはとりあえず気軽な気持ちでテストを実行してみます。
yarn testonly
そうするとウィンドウがたくさん出てきて何も作業ができなくなるので気をつけてください。
yarn testheadless の方がおすすめですが、こちらもかなり時間がかかるので、
最後に一応確認する程度で寝る前に流すなどの方法が良いかなと思います。
実際の確認は、以下のように該当する追加箇所だけを確認する形になると思います。
yarn testonly --testPathPattern "integration" -t "should detect amp validator warning on invalid amp"
一応 yarn lint も通しておくとよいです。
いざ PR を出して...
PR を出す瞬間は緊張しますが、 まあ間違っていても後から直せるので、出してから考えましょう。
PR Template がすでにあるので、各所に適切な内容を追記する形で出せます。 PR を出すと CI が回ります。
テストに通るか確認することもできますし、 stats も見れます。
stats は、以下のようなコメントで、 変更後にビルドサイズが肥大化していないかなど確認できるようになっています。
メンテナからコメントがついたら指示に従うようにしましょう。 マージされれば完了です。
記念スクショ↓
tim さんなどのメンテナから感謝されると嬉しい気持ちになりますね！
最後に
OSS である Next.js のコントリビューション方法の一例を書きました。
そんなこと言ったってバグなんてないし、という方におすすめなのが、 good first issue です。
Next.js の Issue には good first issue ラベルがあります。
https://github.com/vercel/next.js/issues?q=is%3Aopen+is%3Aissue+label%3A%22good+first+issue%22
これは簡単な修正をあえて first contribution 用に残しておいてくれているものなので、手取り早くコントリビューションができます。
また examples はメンテナの目が届かないケースが多いので、コントリビューションチャンスが多いです。 ライブラリの組み合わせは無限大なので examples の追加もいいかもしれません。
僕も OSS のハードルはまだまだ高いと思ってしまっていますが、 簡単な修正でも貢献できそうだと伝われば幸いです。
実際に自分が開発していて困っているなら尚更のこと、 OSS でコントリビューションして自分のために直すところからでもいいと思います。
それが同じ境遇の他の誰かのためになるはずです。
