プロジェクトでnpm依存関係をメンテナンスする方法
José Pérez Rivas
2020年6月11日
0 分で読めます本番環境で問題なく稼働している一方で、積極的なメンテナンスが行われなくなっているプロジェクトはよく見かけます。本番環境で動いていて、クライアントもプロジェクトは完了したと考えている、という状態です。
残念ながら、完全にそうとは言えません。プロジェクトが完了して本番環境で稼働していても、メンテナンスが不要になるわけではないことを忘れがちです。ほとんどのプロジェクトでは、引き続き見直しが必要ですし、問題が起きたら解決しなければなりません。車の購入にたとえるなら、ディーラーに行って気に入った車を選び、代金を払った後は、定期的なメンテナンスを一切せずに、使える間ずっと乗り続けるようなものです。そんなことはしませんよね。ソフトウェアも同じです。
Node.jsでREST APIプロジェクトやCLIアプリケーションを開発する際、オープンソースのパッケージマネージャーであるnpmを使って、フレームワークやツールをプロジェクトに組み込むのは非常によくあることです。
ある程度までは、開発時間の短縮につながるため有益です。十分にテストされ、コミュニティによってメンテナンスされている安定したパッケージを導入すれば、プロジェクトのニーズを満たせます。しかし、逆に問題の原因になることもあります。
ここでは、Node.jsプロジェクトでよくあるシナリオを取り上げます。プロジェクトを放置し、機能改善や予防的なメンテナンスを行わないと、こうした問題が発生することがあります。
具体例
本番環境で2年以上稼働しているNode.jsのREST APIプロジェクトを想像してみてください。この2年間、依存関係を新しいバージョンに更新したり、適応させたりする取り組みは一切行われていません。開発では、CRUD機能のベースとなるフレームワークとしてexpressパッケージが使われていました。また、セキュリティトークンの生成にはjsonwebtokenライブラリが、日付の国際化にはmomentパッケージが使われていました。
考えられる問題
比較的新しい依存ライブラリの使用が、最初の問題として挙げられます。コミュニティによるテストが十分でなく、継続的に開発されていない可能性のあるソフトウェアに、ソリューションの一部を依存させることになるためです。
2つ目は、私が「単独開発者ライブラリ」と呼ぶものに、ソリューションの一部を依存させることです。こうした依存関係は、一人の開発者が改善のリリースやメンテナンス、問題の解決を担い、最終的にはソフトウェアの進む方向を一方的に決めます。このような依存関係は、私たちに大きな制約をもたらします。
3つ目の問題は、ほかの依存関係を含む依存関係です。しかし、これは一見しただけではわかりません。一般に「Node Module Hole」と呼ばれるものです。
出典: https://github.com/JoseJPR/tutorial-nodejs-snyk-vuln-cost/blob/master/assets/video.gif
詳しいヒントはこちらをご覧ください。
解決策
1. その依存関係は本当に必要か？
Node.jsプロジェクトで、まず確認すべきなのは公式ドキュメントです。Node.js APIのドキュメントには、外部の依存関係を使わず、Node.js APIを「ネイティブ」に利用して実現できることを示す、実践的な例が数多く掲載されています。
2. マイクロ依存関係を使う
プロジェクトのニーズを満たす機能が必要だとわかったら、適切なものを探しましょう。最初は、Google検索やnpmの検索エンジンで最初に表示された選択肢が最適だと思いがちですが、そうとは限りません。一度立ち止まって、そのライブラリが提供する機能のうち、実際にどれだけ必要なのかを分析しましょう。必要以上の機能を備えている場合、ほとんど使わないライブラリまでプロジェクトに取り込むことになりかねません。
3. 市場を調査する
少し調査して、代替手段を探しましょう。npmのエコシステムは非常に大きく、ほぼ同じ機能を持つライブラリが複数見つかることもあります。では、どれを選べばよいのでしょうか。この場合、BundlephobiaのようなWebツールを使えば各パッケージのサイズを比較できます。また、npmtrendsでは、ダウンロード数やコミュニティからの貢献など、さまざまな指標を比較できます。
こうしたツールは、適切な依存関係を選ぶうえで役立ちます。依存関係のサイズ、メンテナンスを担うコミュニティの規模、ここ数か月のリリース数、ダウンロード数などは、判断材料として重要です。
4. 予防的なツールを使う
Snykは、Visual Studio Code向けのオープンソース拡張機能Vuln Costをリリースしました。この拡張機能を使うと、package.jsonファイルや、ライブラリのインポートを含む各ファイルから、ソフトウェアに含まれる脆弱性の数を簡単かつすばやく確認できます。
現在、Node.jsプロジェクトではrequireやimportを使って依存関係を取り込めます。許可されていれば、ライブラリ全体を取り込むことも、一部だけを取り込むことも可能です。以下の画像は、先ほど紹介したプロジェクト（express + jsonwebtoken + moment）での例です。
出典: https://github.com/JoseJPR/tutorial-nodejs-snyk-vuln-cost/blob/master/assets/video.gif
Vuln Costの使い方についてさらに知りたい方は、以下の3本の動画をご覧ください。
まとめ
ソフトウェア業界が長年直面してきた課題の一つは、ソフトウェアにはメンテナンスと進化が不可欠であることを説明し、エンドユーザーに理解してもらうことです。たとえば、OSのアップデートへの対応やパフォーマンスの向上、潜在的な脆弱性の解消が必要です。
もう一つの課題は、開発チームが検討や更新、トレーニングに充てる時間を確保し、ソフトウェア開発に最適な選択肢を見つけられるようにすることです。目の前に最初に提示された選択肢が、必ずしも正解とは限りません。
ここで紹介した4つの解決策は、メンテナンスしやすく、高品質で、スケーラブルかつより安全なコードベースの開発に役立ちます。
キャプチャー・ザ・フラッグを始めよう
オンデマンドのバーチャル入門ワークショップを視聴して、キャプチャー・ザ・フラッグの課題の解き方を学びましょう。
