はじめに
FFRIリサーチエンジニアの茂木です。
現代のソフトウェア開発では、OSS を利用することが多くなっています。そうした OSS ライブラリを利用・管理するために、パッケージマネージャーが存在します。その中で、Node.js のパッケージマネージャーである npm で管理されているライブラリ(npm パッケージ）の数は、他の言語の、パッケージマネージャーで管理されているライブラリ数を圧倒しています（図 1)[1]。
そして、フロントエンド開発をはじめとした開発現場では多くの npm パッケージが使われています。 しかし使うためには、極めて膨大な数の npm パッケージの中から、自分の用いるべきものを選定する必要があります。
この選定の補助として、現在広く利用されているのは、npm trends ではないでしょうか。この素晴らしい WEB サイトでは、複数の npm パッケージのダウンロード数の変遷を比較することができます。つまり、似た機能を提供する npm パッケージの中から、最も人気のある npm パッケージを選定することができます。
複数の npm パッケージを比較し、使用するものを選定するにあたって、人気というファクターは非常に有益です。一方で、他にも有益な視点があるのではないか、という考えがある日浮かびました。
それは、「開発の活発さ」です。
人気のある npm パッケージでも、開発が滞ってしまうことは多々あります。一方で、開発の活発な npm パッケージでは、新機能や Bug Fix が迅速に提供されるでしょう。 npm パッケージは、脆弱性や、悪意あるコードの混入が報告されるケースが相次いでいます。そうした際、開発が活発であれば、「目が多いこと」による発見、そして修正が比較的迅速に行われることが期待できます。
無論、OSS は利用だけではなく、貢献も重要です。仮に開発が滞っていても、自身で Pull Request (PR) を出す事ができます。またそれがいつまでも放置されていて、作者がメンテナを募集しているなら、自身がメンテナを引き継いで使うという手もあります。とはいえ、それが常に可能という訳ではないでしょうし、OSS の作者からしても、メンテナの譲渡はリスクのある行為です。
いずれにせよ、開発の場面では npm パッケージの選定は避けられないことです。その指標として開発の活発さは、一つの有益な視点であるのではないかという仮説のもと、次のツールを作成しました。
https://github.com/FFRI/visualize-package
これは、複数の npm パッケージの開発状況の活発さをグラフにより比較できるツールです。
さて、最初に言及すべきことがあります。このツールには現在多くの制限があります。その中でも最も重大なものは、開発がアクティブなパッケージ (例えば React など) では、グラフの値が正確でないことです。GitHub へのログイン (正確には GitHub OAuth を用いた本アプリケーションへの GitHub API 使用の認可) が行われていない場合は、各グラフのデータが 100 件まで、ログインが行われていれば 1000 件まで取得し描画します。それ以前のデータは取得しません。
これは、GitHub API で一度に 100 件までしか情報を取得できないことに起因します。全件のデータを取得することは、API limit rate への抵触や、極めて長い待機時間に繋がります。 現在は、GitHub へのログインがされていれば、API を 10 回まで呼ぶようにしていますが、これでも待機時間を長く感じます。 根本的な解決法は現状思いついていませんが、API を呼ぶ回数を設定可能にしたり、進捗をパーセンテージで表すなどの改善を検討しています。
開発の活発さ
本ツールでは、開発の活発さとして、各月毎の以下のデータがグラフで比較できます。 - Open PR - Open Issue - commit - package update
例えば 2019 年 12 月のデータを見るとします。
commit と package update については、12 月中にあった commit と package update の数の合算です。一方、Open PR と Open Issue の数は、12 月内で Close されておらず、12 月が終わりの時点で Status が Open の PR 及び Issue の数です。
commit と package update の数は直感的にも分かりやすいと思いますが、Open PR 及び Open Issue の数と「開発の活発さ」の関係については考えるべき点があります。これは、PR や Issue が「順調に」消化されているか、を表す面があると考え、実装しました。これが上手く行っているかどうかは、以下の使用例の議論を御覧ください。
使用例
さて、本ツールを使ってみましょう。ただしここで上げられた npm パッケージはあくまでツールの使用例として上げたものであって、利用の推奨・非推奨をおこなうものでは決してないことに留意してください。
まず、リポジトリからツールをクローンしましょう。
git clone https://github.com/FFRI/visualize-package.git
そして、以下の URL に沿って GitHub OAuth の設定を行ってください。
https://developer.github.com/apps/building-oauth-apps/creating-an-oauth-app/
そうしたら、各種設定値を環境変数に設定してください。今回、redirect_url は localhost:1234/ とします。
export NPM_DEVS_VISUALIZER_CLIENT_ID=<your client_id of GitHub OAuth> export NPM_DEVS_VISUALIZER_REDIRECT_URL='http://localhost:1234/' export NPM_DEVS_VISUALIZER_CLIENT_SECRET=<your client_secret of GitHub OAuth>
さて、今回は簡単のため Docker を使って動かすことにします。
cd visualize-package docker-compose up
これにより、localhost:1234 でアプリケーションにアクセスできるようになります。
アクセスしたら、AUTHORIZE APP ボタンを押して、GitHub へログインしてください(図 2)。初回であれば OAuth の連携画面が出てきます。二回目以降は自動的にログインが行われます。
それでは、npm パッケージを検索してみましょう。 あなたはフロントエンドエンジニアで、アプリケーションのなかで、REST API を叩こうとしています。その際に npm パッケージを使うとするなら、どのようなものを使うでしょうか。私であれば以下の 2 つがパッと思いつきます。 - axios - superagent
この 2 つの npm パッケージを npm trends で比較した結果が以下です(図 3)[2]。
axios は superagent の 2 倍以上人気であることがわかります。
では、開発の活発さはどうでしょうか。
まず、本ツールの検索欄で、axios と入力し、エンターキーを押してください。少し待つと、以下のように各グラフが描画されます。ただし、下の GIF 画像(図 4)は GitHub へログインしていない場合です。ログインしている場合は検索時間が長くなるため、検索の方法を解説するのには適当でないと考えました。下の GIF 画像以外の画像は GitHub へログインした状態のものになります。
ここで、グラフは最低でも 2 点ないと描画されません。そのため、出来て 1 ヶ月未満の新しい npm パッケージや、PR や Issue が 1 ヶ月に 1000 (GitHub へログインしていない状態では 100) 以上作られるなど極めて多くたてられた場合に、そのグラフは描画されないことがあります。最初に 4 つ "Too Few Data To Draw A Chart" とあるのは、グラフによって描画される・されないが変わるケースが有るためです。
さて、ツールの操作に戻りましょう。ここで superagent を検索すると、以下のような画面(図 5)になります。ただしここから先は GitHub へログインした状態の画像になります。
画像は画面のほんの一部ではありますが、status が Open の PR の数と Issue の数の推移が完全に写っています。この時点で、あることがわかります。 - axios のグラフが、ある期間まで 0 になっている。
これは前述のツールの制限によるものです。axios は Open PR の数も、Open Issue の数も比較的多いため、10 回のリクエストで拾い切れていません。Open のままの PR や Issue の数は、「溜まっている」と捉える事もできますが、一方でポピュラーなパッケージはそもそも PR や Issue の絶対数が多くなることに留意してください。
さて、今は 2020 年です。この 2 つの npm パッケージを比較して使用しようと思うのであれば、2014 年などのデータはさほど重要ではないかもしれません。その場合、直近の期間にフォーカスして見ることができます(図 6)。
Open PR を 2018 年から、Open Issue は 0 の部分を除外するように 2018 年からフォーカスした結果がこちらです(図 7)。
先程より見やすく、また直近の正確なデータをみることができます (直近から 1000 件までデータが取得されているため、取得直近の方が正しい値になるためです)。これから分かることを考えていきましょう。
- Open PR の数も、Open Issue の数も axios の方が圧倒的に多い。
- axios のそれは、ほぼ単調増加にあった。しかし 2019 年の 11 月を境にして減少している。
- 特に Open Issue は急激に減少している。
- 一方 superagent は単調増加・減少のようなトレンドはない。
- Open PR は 1 桁から 10 程度の範囲で上下している。
- Open Issue は 130 程度で安定していたのが 2019 年に 90 程度まで減少した。しかしその後は 110 程度まで増加している。
commit と package update の推移は以下です(図 8)。
commit に関しては、 - axios は 2018 年 10 月から 2019 年 1 月まで commit がなかった。それ以外はさほど superagent と差があるわけではない。 - superagent は定常的に commit されている。
最後に package update に関しては - axios は数ヶ月に 1 度アップデートがある。 - superagent は比較的頻繁にアップデートがある。
といったことが見て取れます。
さて、superagent の開発の活発さは興味深いです。何倍ものダウンロード数の axios と比べても、開発の活発さはこれほど異なる事があるのです。
axios に関しては、こうした Issue がたてられたこともありました (当時フロントエンド界隈で話題になっていた記憶があります)。superagent と比較すると package update の頻度が少ないですが、commit はされています。さらに Open な PR と Issue の推移を見ると、2019 年の 11 月から開発の活発さが増し、それらが消化されたようにも思えます。しかし、このデータだけでは詳しいことを言うことは不可能です。特に、PR や Issue は superagent より早く消化されているが、人気ゆえ新たな PR、Issue がたてられていて、「溜まって」いるように見えている可能性もあります (とはいえ、commit や package update の頻度を考慮すると、そのような可能性は低そうです)。
今後の展望
おそらく、今後は以下の情報も見れるようにすることが必要でしょう。 - PR の Merge・Close までの平均期間 - 月ごとの新しく出された PR・Issue の数 - 月ごとの新しく閉じられた PR・Issue の数
これらのデータがあることで、Open PR や Open Issue の数が一定であるときに、新しい PR や Issue がたてられては逐次消化されている場合と、そもそも新しく PR や Issue がたてられていない場合を区別できます。
おわりに
さて、今回の記事では、ダウンロード数だけでは分からない、開発の活発さを可視化するために作成したツールをご紹介しました。これは、ダウンロード数だけを見ると埋もれてしまう npm パッケージ(例であげた superagent は決して埋もれていませんが)に、新たな角度からアプローチできます。
私もこれまで REST API を叩くときは fetch API か axios の 2 択で使ってきましたが、今回の比較を通じて、次は superagent を使ってみたいと思いました。
本ツールを npm trends と併用することで、皆様のよりよいプロダクトの開発に貢献できれば幸いです。
エンジニア募集
ＦＦＲＩではサイバーセキュリティに関する研究開発を希望するエンジニアを募集しています。採用に関してはこちらをご覧ください。
出典
[1] Module Counts, http://www.modulecounts.com/. Accessed January 15, 2020.
[2] axios vs superagent vs request-promise, https://www.npmtrends.com/axios-vs-superagent. Accessed January 15, 2020.
