「lib」フォルダーと「vendor」フォルダーの違いは何ですか？

103

ソースフォルダー階層に関してはsrc、コンテンツがわかりやすい、docまたはtestフォルダーなどの一般的な機能が常にいくつかあります。

しかし、大きなプロジェクトにはa libとvendorフォルダーの両方があることに気づきましたが、名前は「libraries外部からのサードパーティ」を含めることを示唆しているため、常に同じだと思っていましたvendors。ただし、同じプロジェクトで両方を見ることは、違いがあることを意味します。

これは実際には何らかの形で一般的な慣行であるにもかかわらず、GoogleやFilesystem Hierarchy Standardなどのソースに関する情報を見つけることができませんでした。

Symfonyのより詳細な例を次に示します。プロジェクトを作成すると、プロジェクトlibのルートにフォルダーが作成されます。このフォルダーには、次の構造があります。

lib
+--filter
+--form
+--…
+--vendor
    +--simpletest
    +--symfony

ここでは、symfonyフォルダーにはすべてのSymfonyのコアが含まれています。

directory-structure

— MattiSG
ソース

3

@YannisRizos私はそれが彼らの情報源にないことを知っています。ただし、プロジェクトの作業を開始してモジュールを生成するとlib/vendor、に沿って他のディレクトリが作成されvendorます。そして、彼らだけではありません。「誰でも任意のディレクトリ構造を選択できます」そうですね、ありがとう。誰でも好きなようにコーディングできます。src「woudzigouga」と呼びたいなら、できます。私ができるかどうかは尋ねませんが、なぜ真剣で有名な他の人が良い習慣のように見える何かをするのかを尋ねています。

— MattiSG

2

明らかなことを除けば、libコアライブラリ（絶対に不可欠なライブラリ、またはフレームワークと同じ作成者から構築されたライブラリ）およびvendorサードパーティライブラリを保持し、他に正気な区別はないと思います。この区別は、さまざまな理由でいくぶん重要であり、一般的な慣行として意味があります。

— ヤニス

1

ところで、質問自体にコメントの説明を追加できますか？

— ヤンニス

@YannisRizosどのような明確化？私の質問を証明するGoogle Code検索は完全に偽ではありませんか？区別が重要な「さまざまな理由」を詳しく説明し、含まれているサードパーティが他のサードパーティよりも重要である方法を説明できれば、実際に役立ちます。含まれている場合、理由はありません。メンテナーは無能でバッチインクルードコードです。

— MattiSG

1

/ lib /にあるものに触れることができますが、/ vendor /にあるものに触れることはできません

— Timo Huovinen

64

libまたはlibrariesディレクトリを見たとき、私は考える：

プラグイン、モジュールなどではなくライブラリ
手続き型ではなく、OOP（該当する場合）（PHPなど）

vendorディレクトリを見たとき、私は考える：

ライブラリ、プラグイン、モジュール、コンポーネントなど。ライブラリだけでなく、サードパーティが提供するもの。
また、アイコンセットなど、コードではないもの。

ディレクトリを見るlibとvendor、いくつかの違いがあります。

libライブラリのみを保持し、vendor実際には何でも保持できますが、
libライブラリを配置するvendor場所、サードパーティ（元の作者によるコードを含む）を配置する場所、
libプロジェクトの元の作者によるライブラリが置かれている場所（それが私でない場合）vendorは、元の作者が第三者に何かを置く場所です。
libプロジェクトの残りの部分と同じライセンスの下でライセンスされているものは何でも安全に想定できます。

上記のいずれが当てはまる場合でも、異なるフォルダを作成するのに十分な理由です。私の知る限り、一般的に受け入れられている慣行はありません。一部のコミュニティには、コミュニティ全体で共通の慣行がありますが、それだけです。

特定のSymfonyの例については、Symfonyはフレームワークであり、開発者が言おうとしていることは、Symfonyアプリケーションでは、フレームワークのコアライブラリはベンダーコードであり、つまりアプリケーションの元の作者ではなくサードパーティから提供されていると思います（君は）。

— ヤニス
ソース

2

「コードではないもの」は、IMHO dataまたはresources（またはに沿ったより正確なものimg）にあります。また、私たちのsymfonyの例では、vendor私はあなたの「原作者」宗派を得ない場合を除き、私はあなたのポイント2と3に適合しないと思うので、実際には、すべてのsymfonyのコアが含まれている

— MattiSG

1

@MattiSGああ、すみません、4つのポイントすべてに当てはまるとは言いません。一つだけです。また、「コードではないもの」はディレクトリresourcesまたはassetsディレクトリに配置する必要がありますが、プロジェクトによってはvendorディレクトリで意味をなす場合があります（私はassets本当に好みです）。

— ヤニス

4

単数形と複数形のどちらが良いですか？libvs libsとvendorvs vendors？

— クアン

4

@Quang私が見た中で最も人気のあるプロジェクトは単数形を使用しますが、どれがより良いかわかりません。

— ヤニス

@YannisRizos：手続き型ではなくOOPをどう思いますか？

— マットオブライエン14年

21

@WayneMの答えを一般化するが、それほど編集することを敢えてしない。

したがって、この構造はアプリケーションフレームワーク（少なくともRailsとSymfony）で観察できるようです。

フレームワークの使用によってもたらされる他のレベルの距離を追加しながら、アプリケーション開発者のためにlib/ src構造を無傷に保つ方法です。フォルダには実際にフレームワークのライブラリが含まれ、フォルダはアプリケーションに含まれるライブラリとソース用に残されますファイル。vendorlibsrc

libフレームワークがなければ、アプリケーションは役に立たないが、アプリケーションの開発者が触れないでください。フレームワークベンダーのライブラリであるため、「より遠い」重要です。

— MattiSG
ソース

10

Symfonyのようなものの場合lib、アプリケーションコード（つまり、開発者によって記述されたもの）でvendorあり、サードパーティのコードです。libはsrc通常のフォルダーであり、vendorはlibであると考えてください。PHPで実際にそのスタイルを見るのは、実際のクラスからHTMLテンプレートを分離するからです。

— ウェイン・モリナ
ソース

2

Railsの資産パイプラインガイド：

app/assets カスタム画像、JavaScriptファイル、スタイルシートなど、アプリケーションが所有するアセット用です。
lib/assets アプリケーションのスコープに実際には収まらない独自のライブラリのコード、またはアプリケーション間で共有されるライブラリ用です。
vendor/assets JavaScriptプラグインやCSSフレームワークのコードなど、外部エンティティが所有するアセット用です。

これはRails固有の質問ではないことは知っていますが、説明はわかりやすく明確であり、おそらく他のフレームワーク/プロジェクト構造にも拡張されています。

— チコ・カルヴァリョ
ソース