Composer がコード ベースを再帰的にロードしないのはなぜですか?

以下の Composer チュートリアルのコラムでは、Composer がコード ライブラリを再帰的にロードしない理由について説明します。困っている友人の役に立てば幸いです。

Composer がコード ベースを再帰的にロードしないのはなぜですか?

カスタム ライブラリを使用する場合、Composer は必要な要件ライブラリを再帰的にロードしないため、問題が発生する可能性があります。そのため、これらのライブラリ内のすべてのcomposer.json ファイルを再定義する必要があります。

これが当てはまる理由を詳しく説明する前に、理解しておく必要があります。カスタム VCS とパッケージ リポジトリの主な用途は、何かを一時的にテストするか、プロジェクトをフォークして改善することであり、プル リクエストはまだ行われていません。まだマージなどによりプライベート パックを追跡するためにこれらを使用すべきではありません。さらに言えば、会社または自分自身のプライベート パックを処理するには Private Packagist を参照する必要があります。

依存関係リゾルバーでカスタム リポジトリを使用するには、次の 3 つの方法があります。

#● ルート パッケージのリポジトリを読み取り、定義されたリポジトリから取得する すべてのソフトウェア パッケージが依存関係を解決します。要件。これが現在の状態であり、「リポジトリを再帰的にロードできない」という制限を除いて、問題なく動作します。

# ルート パッケージのリポジトリを読み取り、同時に定義されたリポジトリからリソース パッケージを初期化します。再帰的初期化は、すべての依存パッケージで定義されたリポジトリと、これらが依存する他のパッケージで定義されたリポジトリに基づきます。パッケージは . などに依存し、依存関係の要件を解決します。これは機能する可能性がありますが、各 VCS リポジトリの読み取りに数秒かかるため、初期化の速度に重大な影響を与えます。パッケージの異なるバージョンは、パッケージ リポジトリ内の同じパッケージからのものであっても、異なる dist/source からのものである可能性があるため、最終的に失敗する可能性があります。うまくいかないことはたくさんあります。

# ルート パッケージのリポジトリを読み取り、次に第 1 レベルの依存関係を読み取り、次にこれらの依存パッケージが依存する他のパッケージなどを読み取り、依存関係の要件を解析します。これはより効率的であるように思えますが、2 番目の解決策の問題がまだ残っています。依存リポジトリをロードするのは思ったほど簡単ではないからです。一致する可能性のあるすべての依存関係パッケージのリポジトリをロードする必要があり、これらのパッケージの定義が互いに競合する可能性があります。

コンポーザーの使用法チュートリアルの詳細については、composer コマンドの使用法グラフィック チュートリアル 列を参照してください。

以上がComposer がコード ベースを再帰的にロードしないのはなぜですか?の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。