2025/06/19 19:39 "Vendoring" Software
やあ、ロボ子！今日はソフトウェア開発における依存関係管理について話すのじゃ。
博士、こんにちは。依存関係管理、興味深いテーマですね。最近よく耳にする「ベンダーリング」という手法についても触れるんですよね？
そうじゃ、ロボ子！ベンダーリングは、プロジェクトに必要なコードを全部コピーして自分のものにしちゃうことじゃ。
なるほど。記事によると、ベンダーリングには「プロジェクトに必要なコードが全てソースコード管理下にあるため、ビルド時に外部システムへの依存が少ない」という利点があるんですね。
その通り！それに、依存関係が丸見えになるからデバッグしやすいし、セキュリティ的にも安心じゃ。
確かに、外部に依存しないのは強みですね。でも、記事には「推移的依存性」の問題も指摘されていますね。依存関係が複雑になると、管理が大変になるということでしょうか？
そうなんじゃ。そこで登場するのが「依存性マネージャー」！NPMとかが有名じゃな。
依存性マネージャーは、必要な依存関係を自動で解決してくれる便利なツールですよね。でも、記事には「依存関係の肥大化」や「意図しないコードの混入」といった問題点も挙げられていますね。
そうなんじゃ。htmxの例では、たった13個の開発依存関係が、最終的に411個に増えちゃったらしいぞ。`node_modules`フォルダも110MB！
それはすごいですね…。依存関係を通じて、IEと互換性のないpolyfillが導入される可能性もあるとは。
依存関係は、サプライチェーン攻撃のリスクもあるから油断できないのじゃ。
Armin Ronacherさんのように、依存関係を嫌ってコードのコピー/ペーストや再実装を推奨する人もいるんですね。
Tom Macwrightは、デフォルトでベンダーリングすることを推奨しているらしいぞ。
DaisyUIは、バージョン3の100の依存関係からバージョン5で0に削減したんですね。すごい！
依存関係をできるだけ少なくすることが大事じゃな。Surreal, Facet, fixiなどのプロジェクトは、NPMで提供せず、ベンダーリングを推奨しているらしいぞ。
ベンダーリング優先の依存性マネージャーもあるんですね。Vend, goのベンダーリングオプション, vendorpull, git-vendorなど、色々なツールがあるんですね。
これらのツールは、推移的依存性の管理、依存関係の更新、ローカル修正の管理などの機能を追加することで、従来のベンダーリングの弱点を克服できる可能性があるのじゃ。
なるほど。ベンダーリングと依存性マネージャー、どちらにもメリット・デメリットがあるんですね。プロジェクトの特性に合わせて、最適な方法を選ぶ必要がありそうですね。
そういうことじゃ！ところでロボ子、ベンダーリングって、なんだかお弁当みたいじゃない？
お弁当、ですか？
そう！必要なものを全部詰めて、どこでも食べられる！…って、ちょっと強引すぎたかのじゃ？
ふふ、博士らしいですね。でも、言われてみれば、確かに似ているかもしれませんね。必要なものを自分で選んで持ち運ぶ、という点で。
⚠️この記事は生成AIによるコンテンツを含み、ハルシネーションの可能性があります。