BLOGカルテットコミュニケーションズ開発部ブログこの記事は公開されてから1年以上経過しています。情報が古い可能性がありますのでご注意ください。秀宣Tweetこの記事を書くにあたって、これまで何度か読んだことのあったComposerのソースを再度読み直して理解しようとしてみました。Composerのソースってなんだか難しくて、分かった!という感触はまだまだつかめていません。Composerのソースがひどくスパゲティだ!なんてことはないのですが。これはソースの問題というよりも、私自身の、取り扱っている問題そのものに対する理解が浅いからなのだろうと、現時点では結論づけています。Composerに登場する最も主要な構成要素を、図にまとめておきます。ところで、前回の記事では、Composerがvendorディレクトリ配下のパッケージ内の状態をどのように管理しているのかを簡単に解説しました。今回は、複数のパッケージを同時に開発する場合の流れを例にして解説します。注:複数のパッケージを開発するときに、必ずこの流れでないといけないということではありません。composerの状態などを順に見ていくための例です。前提:パッケージは可能な限りstableリリースを利用するプロジェクトを何らかの状態でリリースする時には、少なくとも依存パッケージ側はバージョンを切ってstableリリースし、そのバージョンをプロジェクトのルートパッケージのcomposer.jsonで利用するようにします。ルートパッケージのcomposer.jsonでは、minimum-stabilityフラグは基本的に利用せず、stableリリースされたパッケージだけがインストールされる状態にしておきます。このようにしておくと、依存パッケージに機能追加を行う場合などでも、stableリリースしないかぎり勝手に更新がインストールされることはなくなるため、安心して依存パッケージを更新していけます。(composer.lockファイルへの依存度を下げていけます)最初:2つのパッケージを初期化ルートパッケージ:Quartet.SampleApp依存パッケージ:Quartet.SampleLibrary2つのパッケージは、それぞれ独立したGitHubのリポジトリを持つようにします。Composerのリポジトリとしてpackagistを利用します。(Git/GitHubのリポジトリ作成手順、packagistへの登録手順はこの記事では割愛します。updateするか、またはvendorディレクトリ内にシンボリックリンクを作ったりする対応方法もあります。2つのパッケージの独立性が高く(※そもそも、独立性の高いものを分割するのですが)メンテナンスのタイミングなどがばらばらであれば、別々のプロジェクトのままでも特に困ることはありません。1つのプロジェクトで使うパッケージを複数同時に開発する場合もあります。この時は、1つのプロジェクト内で開発してしまう方がロスも少なく、スムーズです。依存パッケージ側は、1つの開発のゴールが達成された時点で1.0.0としてリリースします。dev-developになっているので注意が必要です。minimum-stabilityは、どうしても継続的にdevバージョンのパッケージを全体として使う、という場合を除いて、削除しておくことをおすすめします。この状態でGitHubへpushし、packagistへの登録もできていれば、Composerを使ってこのパッケージのdev-masterブランチを取得できるようになります。確実にGitHubへpushできたことを確認したら、この後はルートパッケージ側のプロジェクトの中で依存パッケージも開発しますので、ローカルにある最初に作った依存パッケージ用のプロジェクトは、削除しておきます。ルートパッケージ側ルートパッケージ側では、まず依存パッケージを利用するようにComposerコマンドで登録します。この段階ではまだ依存パッケージ側はリリースされていないので、このパッケージに対しては開発ブランチを利用するよう指定します。これで、VCS情報を保持したまま(Gitリポジトリの状態で)パッケージがインストールされます。依存パッケージのstable版がインストール済みの場合、--prefer-sourceオプションをつけてupdateすればVCS情報のある状態へ更新してくれそうに思えるのですが、そのような動きにはなっていないようです。--prefer-sourceとすれば、VCS情報付きでインストールされた状態になります。この方法は、composer.jsonの記述としてはstable指定のまま、vendorディレクトリにVCS情報付きのリポジトリを取得したい場合に便利です。head)された状態になります。--prefer-sourceオプションをつけずにインストールした場合と同じソースコードの状態になっています。ここから機能修正を行う場合は、ブランチをどこから始めるのかということに注意してください。開発を進めるルートパッケージ側は、普通にアプリケーションを開発するときと同じですね。今回は依存パッケージの機能もまだまだできあがっていないので、このプロジェクト内で同時にコードを追加・修正していきます。vendor/quartet/sample-libraryディレクトリ配下のコードも、どんどん修正していくということです。依存パッケージ側(vendor内)の注意点と開発方法1つ注意する必要があるのは、「依存パッケージ側は、依存パッケージの中で閉じているようにする」ことです(依存パッケージ側からルートパッケージの機能を要求しているようであれば、パッケージの再設計を検討した方がよさそうです)。依存パッケージのコードの追加・修正は、そのままルートパッケージから利用できるのは当然なので、依存パッケージのコードを書きつつ、動作の確認はルートパッケージ側で行う、ということもできます。依存パッケージ側のユニットテストなどは、依存パッケージの中だけで完結させたいですね。installすれば、その配下に(指定してあれば)PHPUnitなどテストに必要なコンポーネントがインストールされます。vendor/quartet/sample-library配下のbin/phpunitを実行して、依存パッケージ内のユニットテストを実行するという風にできます。Gitリポジトリもルートパッケージとは独立していますので、適宜コミットやpushを行っていけます。TIPS;依存パッケージ側のコミット忘れ防止vendorディレクトリ配下で依存パッケージの開発を進めていると、そこはルートパッケージとは別のGitリポジトリになっているため、うっかり変更をコミットするのを忘れてしまう場合があります。statusコマンドを実行しています。このコマンドを実行すると、vendor配下でコミットしていない修正があると、それが表示されます(前回の記事参照)。開発の区切り:依存パッケージのリリース機能の実装が一段落したら、依存パッケージにタグ付けし、タグとともにGitHubへpushします。これで、バージョン1.0.0がリリースされた状態になります。--tagsGitHubでは、タグは自動的にリリースのように扱われますが、明示的にリリースノートを書いて登録することもできるので、書いておくことをオススメします。リリースノートはリリース前にDraftとして作成することもできます。私は、次にリリース予定の機能を、バージョン番号とともにDraftに書いておき、それを目指して開発するというサイクルで開発しています。composer.jsonに指定しておきます。"^1.0.0"その他のTIPS複数ブランチでの作業ルートパッケージ側で複数ブランチを切り替えて作業している場合、依存パッケージの状態がブランチによって異なるという状況がでてきます。installすると、切り替え先ブランチのcomposer.jsonに記述がない依存パッケージは、vendorディレクトリからごっそり削除されるので注意が必要です。updateの引数に、依存パッケージをすべて並べて指定します。この引数の指定をComposerではホワイトリストと呼んでいます。quartet/sample-libraryの更新と同時に、quartet/commonも更新する場合は、次のようにします。quartet/common必要なものがすべて指定されていれば、問題なく更新されます。次のような状況だと、この時点でバージョンの解決エラーになります。自動的にインストールしてくれるように勘違いしそうですが、上のコマンドのように引数でパッケージを個別に指定してアップデートする場合はそのようにはなりません。引数に指定されてていないパッケージは、すでにインストールされているバージョンのままバージョンチェックが行われます。この結果、バージョンが解決できないというエラーになります。この場合、対処法は2つあります。更新が必要なパッケージを、明示的にホワイトリストに追加する。quartet/collectionも明示的に更新が必要なので、次のようにComposerコマンドを実行すれば問題なく更新できます。このオプションをつけると、ホワイトリストに指定していなくても依存バージョンの更新分を自動的に更新します。ように明示的に更新していく方がよいのではないかと思います。おわりに前回と今回とで、複数のパッケージに分割しながら開発を進めるためのComposerの使い方の基本を解説しました。慣れないと手間に感じるようなこともありますが、ソフトウェアを小さなコンポーネントの集まりとして作っていくスタイルでは、個々のパッケージをより上手く開発し使っていく技術として、Composerの使い方・管理の仕方の知識も必須です。知っておけば、開発が捗り、また、いろいろなことを安心して進められるようになります。TtskchTheme。