私は、自分の新しい光沢のあるパッケージであるパッケージ P への依存関係を定義する composer.json ファイルを持つアプリケーション A を持っています。私のパッケージ P には、ライブラリ L とフレームワーク F への依存関係を定義する composer.json ファイルがあります。私のパッケージ P にはまだリモート リポジトリがなく、packagist.org にもまだ公開されていません。ブラウザでアプリケーション A を実行し、アプリケーション A が依存するパッケージ P を継続的に変更します。
私にとってワークフローを本当に複雑にする問題がいくつかあります。
1) A から P への依存関係の定義は、ここで説明されているように、ローカル リポジトリを使用してのみ可能です: https://getcomposer.org/doc/05-repositories.md Aで実際にテストできます。
2) 1) を参照すると、これは、composer update
P に変更をコミットするたびに実行する必要があることを意味します (そもそもコミットしたくありません)。
3)一方、 P でローカル リポジトリを使用しない場合、A から P への実際の依存関係を定義できません。つまり、実行してcomposer install
も、P の composer.json ファイルで定義された依存関係 L および F がインストールされません。
したがって、私の意見では、2 つのワークフローが考えられます。
1) P の変更を A にコミットしcomposer update
、変更がどのように機能するかを確認します。
2)依存関係としてローカル リポジトリを使用せず、P の composer.json ファイルで定義されている依存関係を A の composer.json ファイルにコピーcomposer install
して、依存関係 L および F を取得するために使用できるようにします。
基本的に、私はcomposer install/update
すべてのサードパーティの依存関係をインストールするために実行できる新しい composer パッケージを開発するためのワークフローを探していますが、変更をテストするために自分のローカル パッケージに変更をコミットする必要はありません。
上記の問題に対する解決策はありますか?
どうもありがとう!