はじめに
皆さん、npm パッケージを使用する際、公式のドキュメントを読みにいくは当たり前の動きになっているかと思いますが、せっかくならそのパッケージに貢献したいと思ったことはありませんでしょうか？
今回は個人的にパッケージ貢献するため、実際にしたことを記事にまとめようと思います。
パッケージ貢献
本記事で言うパッケージ貢献とは、下記を指します。
- 外部パッケージに対し Pull Request を作成する
- 外部パッケージに対し Issue を立てる
- 外部パッケージに対し Discussion に参加してみる
個人的に行った対応内容
実際のソースを確認する
こちらは、実際のソースを読みにいく動きをすることでドキュメント以上の理解を深めることができます。
実際に公式ドキュメントには載ってないけど、ソースを見にいくと「あ、この書き方もできる」みたいなことがあったりします。
実際のソースを確認することで、そのパッケージの構成への理解をすることも可能になったりします。
- この UI パッケージは vue だけど tsx で作成されてる
- このパッケージはモノレポで作成されてる
- etc...
また、外部パッケージで使用しているパッケージに対してもいい発見があります。
ここまででも結構メリットだらけです。
ただ、ソースを読めるくらいのレベルにならないと結構諦めがちになるので、とにかくソースを見る・書くを繰り返さないといけません。
AI のソースをそのまま使用しない
最近の開発では、AI を使用してソースを組むことが当たり前になってきています。
ただ、AI を使用したソース開発で、そのソースを内容を簡単にだけ確認してコミットするような実装だと、貢献活動は遠のいてしまいます。
AI のソース開発を否定するわけではありません。ただ、そのソースをしっかり確認するようにしましょう。
確認内容としては下記です。
- ロジックの読解
- パッケージの関数を使用された場合は、その関数のドキュメントを確認する（またはソースを確認する）
そうすることで、しっかり中身を理解した開発ができるかつ、パッケージに対する理解も深まると思います。
最新のバージョンが出たらすぐ試す
こちらは、個人開発のソースではなく、現場で実際に触れているソースに対して実施しましょう。
理由としては、現場のソースはある程度規模が大きくなっているからです。そういったプロジェクトに最新のバージョンを適応してみるのです。
そうすると実際の動作確認でうまく動かないことに出会しますが、それが最新バージョンによるアプリケーションロジックの不正なのか、最新バージョンでの不具合なのかを確認することができます。
自分はそれを試して何個か不具合を見つけ、issue を立てたことがあります。
一番使用しているパッケージの issue 情報を常に確認する
こちらは、どのくらい不具合があるのかや、今後どのような機能が追加されるのかを確認するためにも実施した方が良いものとなります。
また、確認しておくと、どのように issue を立てれば良いのかもわかってきます。
ソースコードを確認する運用が続いていれば、その issue に対しての Pull Request を立てることも可能だったり？
「消費者」から「当事者」への意識改革
ライブラリで問題が発生したとき、「このツールはダメだ」と切り捨てるのではなく、「なぜだろう？」「どうすれば改善できるだろう？」 と考えてみましょう。そのパッケージは、誰かが時間を割いて作ってくれたものです。その問題の原因を突き止め、解決策を提案できれば、それは立派な貢献になります。
普段使っている npm パッケージやフレームワークは、完成された製品ではなく、世界中の開発者によって日々改善が続けられている「生きたプロジェクト」です。ソースコードを読んでその仕組みを理解しようとすることで、改善点やバグに気づきやすくなります。
エラーメッセージと深く向き合う
エラーが出た際、Stack Overflow で見つけた解決策をコピー＆ペーストして終わりにするのではなく、「なぜこのエラーが起きたのか」をライブラリのソースコードレベルで追ってみましょう。エラーハンドリングの不備や、特定の条件下でしか発生しないバグを発見するきっかけになります。
まとめ
ここまでまとめさせていただきましたが、実際に対応してみて、Pull Requst をあげたこともありますし（マージできませんでしたが・・・泣）、Issue を立てたこともあります。Discussion への参加もしたことがあり、そちらでは問題の解決のコメントもさせていただくことができました。（これは非常に嬉しかったです）
皆さんも是非、外部パッケージへの貢献をしてみてはいかがでしょうか？