PHPerのための「Composer」を語り合うPHP TechCafe LT資料

1. Composer bin plugin
ツールの依存管理から解放される

2. Composer bin pluginとは？
• composerでインストール
するツールを独立して管
理するプラグイン
• 実行ファイルは引き続き
vendor/bin/に設置される
• php-5.5.9より利用可能
https://github.com/bamarni/composer-bin-plugin

3. 依存関係競合とは
https://github.com/FriendsOfPHP/PHP-CS-Fixer https://github.com/spatie/phpunit-watcher

4. 依存関係競合とは
1. phpunit-watcherをインストール
2. php-cs-fixerをインストール
インストール成功
1. php-cs-fixerをインストール
2. phpunit-watcherをインストール
インストール失敗
「spatie/phpunit-watcher version Xはyosymfony/resource-watcher version Yを必要と
している。 yosymfony/resource-watcher version Yはsymfony/finder version Zを必要と
している。しかしsymfony/finderは既にVersion Aがインストールされているため依存を
解決できずインストール失敗」
…と、全バージョンの組み合わせで書いてある。
解決方法
• エラーメッセージや既存パッケージの依存関係を調べる。
• インストールしようとしているパッケージと競合しない既存パッケージのバージョン
を特定する。
• 既存パッケージのバージョンを変更した後、目的のパッケージをインストール
※2022年6月時点の実行結果

5. 依存関係競合とは
https://readouble.com/laravel/9.x/ja/upgrade.html#updating-dependencies
Laravel以外の箇所も書き換えなければ
ならない。
Laravelをアップグレードしたい。
対象はどれ？
具体的にどのバージョン？

6. 依存関係競合とは
対象はどれ？
具体的にどのバージョン？
※あくまでサンプル
2022年6月時点ではこの組み合わせではエラーは発生しない

7. Vendor binaryとして配布されるツール
• 単独で動作するツールとして作られていることが多い。
• アプリケーション本体と同居させず独立して管理したい。
• 開発環境としてバージョン管理は行いたい。

8. 従来の解決策
• グローバルインストール
composer global require awesome/tool
• ✕ バージョン管理不可（メンバー間のバージョン差異）
• ✕ Docker環境としての配布が困難
• △ 環境構築がひと手間増える
• 専用フォルダにローカルインストール
composer --working-dir=path/to/tool awesome/tool
※php-cs-fixerはこの方法を推奨している
• ○ バージョン管理可能
• ○ Docker環境としての配布が可能
• △ 環境構築がひと手間増える
• △ 標準外フォルダよりツール起動（プロジェクト固有知識）

9. Composer bin plugin
• ○ 本体とツールとを分離して管理
• ○ バージョン管理可能
• ○ Docker環境としての配布が可能
• ○ 環境構築の手間は変わらない
• ○ 標準フォルダよりツール起動可能

10. インストール・使い方
• プラグインをrequire-devとしてインストール
• 「名前」を指定してパッケージをインストールできる。
• 「bdd」という名前でphpspecをインストール
• 「etsy-phan」という名前でphanをインストール
• 「phpmetrics」という名前でphpmetricsをインストール

11. どのように動作するのか？
独立して管理
独立してインストール
ツールの起動は従来のパスより可能
（vendor/binにリンクが配置される）
• ○ 本体とツールとを分離して管理
• ○ バージョン管理可能
• ○ Docker環境としての配布が可能
• ○ 環境構築の手間は変わらない
• ○ 標準フォルダよりツール起動可能

12. git管理
配下のvendorは
git管理除外
composer.jsonは
ツール毎にgit管理
Composer bin plugin管理
※インストール時に自動設定される
.gitignore追記
• ○ 本体とツールとを分離して管理
• ○ バージョン管理可能
• ○ Docker環境としての配布が可能
• ○ 環境構築の手間は変わらない
• ○ 標準フォルダよりツール起動可能

13. 管理の自動化
https://getcomposer.org/doc/articles/scripts.md#command-events
参考：Composer Scripts / Command Events
pre-XXX-cmd / post-XXX-cmd
• composer XXXが実行された前や後に指定コマンドを実行
• composer.jsonのscriptプロパティで設定
• composer installが実行されたら
composer bin all installも自動的に実行
• composer updateが実行されたら
composer bin all updateも自動的に実行
• 上の２つの設定のショートハンド
• ○ 本体とツールとを分離して管理
• ○ バージョン管理可能
• ○ Docker環境としての配布が可能
• ○ 環境構築の手間は変わらない
• ○ 標準フォルダよりツール起動可能

14. まとめ
課題
1. Composerは依存関係の競合が発生することがある。
2. 単体で動作するツールは独立して管理すべき。
3. Composer標準の方法にはデメリットある。
解決
• Composer bin pluginの導入
• 依存関係の競合は発生しない
• ツールの起動は従来と変わらない
• 環境構築は自動化可能
• 利用者はプラグインの存在を意識しなくて良い
参考資料
• このPHPがテンプレートエンジンのくせに慎重すぎる
(前篇) / @tadsan
• Composer bin plugin — Isolate your bin dependencies
• Vendor binaries and the vendor/bin directory -
Composer
• Scripts - Composer