2,107 測定値

適切な依存関係の選択: 包括的な実践ガイド

に Daniil Sitdikov5m2023/04/17

長すぎる; 読むには

本当に必要ですか？おそらく、あなたの環境にはすでにすべてが揃っています。わかりました、必要です。まず、セキュリティについて考えてみましょう。どのくらい安全に使用できますか?次に、メンテナンス。最後のリリースはいつですか？リリースはどのくらいの頻度で発生しますか?問題。未解決の問題と解決済みの問題の比率は?その他のポイント: コードの品質、テストカバレッジ、ライブラリのサイズ、依存関係の数、およびライセンス。

あなたがミシュランの星を獲得した高級レストランのシェフだったとしたら、検証されていないランダムなソースから野菜や肉を購入しますか?ほぼすべての平均的なプロジェクトのコストは、数十万ドルまたは数百万ドルにもなります。私たちの業界は飲食店と同じアプローチをとるべきだと思います。

すぐに自問する最初の質問: 本当に新しい依存関係が必要ですか?言語やインストールされているライブラリなど、現在の環境を使用して問題を解決できますか?たとえば、UUID を生成するために追加のライブラリをインストールする必要はありません。 Node.js とブラウザーは、すぐに使用できるようにサポートしています: crypto.randomUUID()

2 番目の質問: ライブラリ全体が必要ですか?たとえば、ドロップダウンのみが必要な場合、Bootstrap などをインストールする価値はありますか?おそらく、 Radix UI のスタイル設定されていないドロップダウンコンポーネントを使用して、焦点を絞った単一のライブラリに限定する方がよいでしょうか?

わかった。私たちはいくつかの候補を考えています。では、正しいものをどのように選択すればよいでしょうか。

美しくフォーマットされた README?有名な名前？他のフォークよりも多くのフォーク、スター、ダウンロードがありますか?残念ながら、これらの要因だけでは十分ではありません。ここでは、サービスプロバイダーを選択しています。発生した問題を迅速に解決し、機能を最新の状態に保ち、何よりもサービスが安全で信頼できるものであることを願っています。単純な外部指標は、常に品質や長期的な適合性を示しているわけではありません。リポジトリカタログで見つけたものをインストールする前に、GitHub リポジトリにアクセスしてその内容を分析することをお勧めします。

ここ数年使用している基準のリストを用意しました。最適なライブラリを選択するのに役立つことを願っています。それらを包括的に検討し、場合によっては妥協して選択することが不可欠です。

免責事項:以下に挙げるライブラリを批判したり、使用を思いとどまらせようとしているわけではありません。場合によっては、事実の正確さを維持しながら、基準の例に焦点を当てるために意図的に名前を省略しています。

1. セキュリティ

どのくらい安全に使用できますか?フィクションのように聞こえるかもしれませんが、そうです、依存関係は危険な場合があります。たとえば、50 万回のダウンロードがあるライブラリに興味深い機能が追加されました。IP アドレスが特定の範囲内にある場合、コンピューター上のすべてのファイルを ❤️ に置き換えようとします。

興味深い事実は、この依存関係がvue-cliで使用されたことです。どうすればそのような問題を発見できるでしょうか?問題のページを確認するか、図書館の名前でグーグル検索してみてください。通常、そのような情報はすぐに表面化します。

2. メンテナンス

最後のリリースはいつですか？リリースはどのくらいの頻度で発生しますか?定期的なリリースにより、問題が解決され、更新が絶えず変化するテクノロジをサポートすることが保証されます。モバイル開発のコンテキストでは、定期的なリリースによって、プロジェクトが正常にコンパイルされることも保証されます。

Go の世界からの例を次に示します。18.2K の星を持つライブラリの作成者は、依存関係の維持をやめてアーカイブすることにしました。これは、数年以内に、サポートと更新の欠如が問題になることを意味します.最初に GitHub をチェックせずに同様の依存関係をインストールすることを想像してみてください。商品の賞味期限をチェックするようなものです。

以下は、頻繁にリリースされる良いリリースの例です。

3. オープン/クローズ済みの問題

未解決の問題と解決済みの問題の比率は?著者はどの程度変更を受け入れようとしていますか?いつか何か貢献する必要があるかもしれません。たとえば、このライブラリは非常に人気があり、98% の割合で解決済みの問題があります。開いているのは18のみです。
重大な問題はどのくらいの速さで解決されますか?一度、31,000 スターの ORM を選択しましたが、ある時点で問題が発生してブロックされました。回避策を探し、最終的に別のソリューションに切り替える必要がありました。残念ながら、4 年近くが経過しましたが、問題はまだ解決されていません。
このような問題は、コメントの多い順に並べ替えることで特定できます。
投稿プロセスはクリエイターによって組織されていますか?明確で定義されたワークフローが整っていますか?たとえば、Next.js の作成者は、貢献プロセスに関する 40 分間のビデオを録画しました。

4. コードの品質

はい、多くのコードが存在する可能性がありますが、そのさまざまな部分を調べることは常に可能です。プロジェクトはどのように組織されていますか?理解しやすく、適切に構成されており、適切なプラクティスが適用されていますか?コードの書き方が悪いほど、将来的にプロジェクトが崩壊する可能性が高くなります。私にとって、この段階で多くの小さな候補者が排除されました。

5. テストカバレッジ

ライブラリにはテストがありますか?テスト範囲は？テストはどのように書かれましたか？メンテナーがマージリクエストをレビューしても、何かが見落とされる可能性があります。図書館にはさまざまな人が貢献しています。通常、テストカバレッジ情報は、リポジトリの上部にあるバッジに表示されます。ただし、そうでない場合は、いつでもプロジェクト内のテストを検索できます。たとえば、 formatjsライブラリファミリは優れたテストカバレッジを備えており、さまざまな種類のテストが含まれています。

6. ライブラリのサイズ

多くの場合、モバイルアプリケーションは依存関係のサイズが大きく、アプリ全体が 200 MB を超えることもあります。これにより、セルラーネットワークのダウンロード中に問題が発生し、大量のストレージスペースが消費される可能性があります。これは、インターネットの速度が遅いと読み込み時間が劇的に長くなる可能性があるフロントエンド CSR アプリでは特に問題になります。

Web プロジェクトの場合、パッケージサイズを決定するための優れたツールがあります: https://bundlephobia.com 。もちろん、サーバー側のレンダリングとツリーシェーキングによってサイズが小さくなる可能性はありますが、これは常に検証する必要があります。

よくある例は、日付操作ライブラリです。 dayjs (2.9KB) によって提供される機能で十分な場合があり、 moment.js (72.1KB) またはdate-fns (26.8KB) をインストールする必要はありません。

7. 依存関係の数

上記のすべてのポイントは、プロジェクトの依存関係ツリー全体の依存関係の数によって、ある程度乗算されます。完全な依存関係ツリーを確認するための優れたツール: https://npm.anvaka.com

8. ライセンス

これについて考えたことはありますか？私もそうではありませんでした。たとえば、MIT および Apache 2.0 ライセンスでは商用プロジェクトでライブラリを自由に使用できますが、一部の GPL v2 ライセンスには特定の要件と制限があります。私たちのプロジェクトの 1 つでは、すべての依存関係ツリーのライセンスをチェックするために、弁護士が作成したテーブルがありました。したがって、ライセンスに何か異常がある場合は、監査中の問題を回避するために弁護士に相談することをお勧めします。 legallyユーティリティを使用して、既存の npm 依存関係からすべてのライセンスを抽出できます。 PS 私は弁護士ではありません。これは法的助言ではありません。ライセンスが原因で何かが適切でない可能性があるというまれな特殊なケースですが、それでも可能です。