いまさらComposer
- 1. @mkkn_info
- 4. u Composer = 依存関係管理理ツール u 依存関係 = プロジェクトやライブラリが 必要/前提とするライブラリの情報 u ライブラリをダウンロードして… u プロジェクトに組み込む u Include_pathに突っ込む
- 5. SOURCE library A library B SOURCE library A library B SOURCE library A library B
- 6. SOURCE library A library B SOURCE library A library B SOURCE library A library B ここにも ここにも ここにも
- 7. SOURCE library A library B SOURCE library A library B’ SOURCE library A library B いつの間にかB’に 元のverっていくつだっけ…？
- 8. u プロジェクトにライブラリが混⼊入すると u 誰かがライブラリを改変するかもしれない u バージョン管理理にバージョン管理理したくない コードが混⼊入する。 u include_pathに組み込むと u 環境構築⾯面倒 u ライブラリのバージョン管理理は？ u 「基本仕様書 – 依存ライブラリ の項を参 照…」みたいな
- 9. u PHPの依存関係管理理ツール u 現在のPHPでは事実上の主流流ツール u composer.jsonに使⽤用ライブラリ(依存関 係)を記述 u composerコマンドで各環境毎にライブラ リを調達する
- 11. u プロジェクトとライブラリを分離離できる。 u 使⽤用ライブラリ情報はcomposer.jsonに記述 するだけ u プロジェクトのバージョン管理理に余計なファ イルが⼊入らない。 u 環境ごとにそれぞれでライブラリを調達。 u バージョン情報も⾃自動的に記録される。 u ライブラリxxxのバージョンxxxを使⽤用…など
- 13. u COMPOSER実⾏行行環境の準備 u ライブラリの名前調べる u プロジェクトに依存関係定義 u インストール u ライブラリの利利⽤用
- 14. u composer.phar ファイルさえあればOK u インストールの必要なし u プロジェクトファイルに含めとけば、チーム 内への頒布/導⼊入も楽 u composer.pharにパスを通せば、グロー バルにも使える。
- 16. u COMPOSER経由のインストールは Packagist登録ライブラリを⽤用いるのが楽。 u コマンドでPakckage名を検索索できる u vendor_name/package_name u 余⼒力力があれば、バージョン情報も u PackagistのWEBページでも
- 18. u ライブラリの登録もコマンド経由で u composer.jsonが⾃自動的に更更新される。 Packagist登録名 通常 vendorName/libNameの形式 バージョン番号 Gitのブランチやタグが使える。 タグ :tagname ブランチ :dev−branchname
- 19. u ライブラリ群のダウンロードもコマンド 経由で。関連ファイルが⽣生成される u composer.lock u vendor ディレクトリ u プロジェクトからvendor/autoload.php をrequireすれば完成。
- 20. u ライブラリ群は全てvendorディレクトリ にダウンロードされる。 u ファイル内でvendor/autoload.phpを requireすれば、クラス利利⽤用時に⾃自動でラ イブラリがロードされる。 u 個々のライブラリ毎にrequire_onceとかする 必要なし。 u フレームワーク組み込み系のComposerはこ の辺⾃自動でやってくれてるケースが殆んど。
- 22. u installコマンド実⾏行行後でも、requireコマンドでラ イブラリを追加できる。 u 追加後、lockファイルが更更新される。 u ライブラリを最新のバージョンに更更新する場合に は、updateコマンドを使⽤用する。 u 引数を付けない場合、全てのライブラリが更更新され る。 u 更更新とともにcomposer.lockファイルも更更新される。
- 23. u composer.lock ファイルにインストールし たバージョン情報が全て書き出される。 u dev-master等の曖昧なバージョン情報を解決 u composer.lockがある環境でinstallコマンド を叩いた場合、ファイルに記載された通りの バージョン情報を再現してくれる。 u デプロイファイルに含めておけば、開発環境から リリース環境まで同じ状況を再現可能。 u GITフックにねじ込むとかで⾃自動ライブラリ 更更新
- 24. u とりあえず以下の3つをバージョン管理理に 含めとく u composer.phar: みんなで使うComposer u composer.json: 構成情報 u composer.lock: バージョン情報 u vendorはバージョン管理理に含めない u デプロイ時にデプロイ先環境で composer install 実⾏行行する
- 27. u requireコマンドにdev オプションをつける と通常のrequireエントリとは別の”require- dev”エントリに依存関係が記述される。 u リリース環境などでは、--no-devオプション を付けてinstall/updateすることで、 require-devエントリの依存関係処理理をス キップできる。
- 29. u 多少⾯面倒だが、Packagist経由でないイン ストールも可能。 u Packagistで公開しなくても⾃自作ライブラリ をComposerで使える!! u vcs: GITやSVN等のリポジトリ u pear: pearリポジトリ u package: ⼒力力技 u composer: composer リポジトリの追加 ⾃自分でPackagist以外のComposerリ ポジトリ⽴立立てる⼈人向け
- 30. u 任意のGITリポジトリが利利⽤用可能 u GIT以外にもSVNとかのURLも使えるらしい。 u Github,Bitbucket のURLを登録している場合、gitク ライアントがなくてもdistでzip形式のダウンロードを 実⾏行行してくれる。
- 32. u ⼒力力技でSmartyも 配布先情報は、distか sourceどちらかが必要。 両⽅方書いてもいい。 versionは.lockファイルに 影響してくるので、記述 しておくほうほうがいい。
- 34. u dev-master ってなんよ？ u → masterブランチのこと u Composerにおけるバージョンは、基本的に tagとbranch u tag名はそのままバージョン名になる u branch名は dev-{ブランチ名}でバージョン名に なる。 u ライブラリ側のcomposer.jsonでversionを指定 することもできるが、あまり推奨されていない。
- 35. u tag名はそのままバージョン名になる u X.Y.Z’ または ‘vX.Y.Z’の形式 u 末尾に,-patch, -alpha, -beta, -RCを付与で きる(オプション)。 u 1.0.0 u v4.4.4beta2 u v2.0.0-alpha
- 36. u branchは、dev-{branch名}の形式で バージョンとして利利⽤用できる。 u dev-master : masterブランチ u タグの規約に沿った形のブランチ名は、 {ブランチ名}-devがバージョン名になる。 u 2.0.x-dev : 2.0ブランチ または2.0.x ブラン チ u ブランチのバージョンは開発バージョン として解釈される。
- 37. u バージョンに別名をつける。 u ⾃自⾝身のdev-masterに1.0.x-dev相当のバー ジョンを付与する。 u 例例えば、バグフィックスをフォークリポジト リで取ってくるときとかに。
- 39. u 依存関係定義時に、バージョンを指定。 u バージョンを調べるのは⾯面倒。 u 毎回dev-masterじゃいかんの？ u バージョン指定してcomposer.json作る ならlockファイルとかいらなくね？
- 40. u requireでバージョン指定していれば、 composer.lockは不不要？ u 下位のライブラリの依存関係周りで詰む lib A lib B lib C require libB:2.0.0 require libC:dev-master
- 41. u composer.lockがあれば、requireは基本 dev-masterでOK？ u 安定版ソースでもsource扱いになってしまう。 u composer update しないなら問題ないん じゃない？ u dev-masterは⼀一応開発版バージョン。 minimum-stability周りに引っかかると厄介。
- 44. u require 欄にはPHP環境構成についての記述を⾏行行 うこともできる。 u php: PHPのバージョン ex. >=5.4.0 u php-64bit: 64bit版PHPのバージョン指定 u hhvm: HipHop Virtual Machineのバージョン指 定 u ext-<name>: ext-mbstring,ext-gdといった具合 にPHP拡張を指定する。バージョンという概念念は あまりなさそうなので右辺には * を指定するのが ⼀一般的 u lib-<name>: curl, iconv, icu, libxml, openssl, pcre, uuid, xslなどのPHPが依存するライブラリ群 のバージョン指定
- 47. u dist: .git ついてこない。 u source: .git ついてくる。 u --prefer-dist,--prefer-source オプションで 動作を強制できる。 u デフォルトでは、安定版のダウンロードは dist、開発版のダウンロードはsourceとなる よう。 u dev-masterはブランチバージョン指定なので開 発版扱いでsourceがデフォルトとなる u 1.0.0はタグバージョン指定なので、安定版扱い でdistがデフォルトとなる。
- 49. u requireの戻り値でオブジェクト受け取れ る。 u ComposerAutoloadClassLoaderクラス のインスタンス u require後にクラスマップやPSR系の設定追加 ができる(動的オートローダ)。 u Composerだけでマイクロフレームワークっ ぽいの作るときとかに。
- 55. u satis : composer リポジトリビルダー u packagist的なComposerリポジトリを⾃自分 で作成してホスティングできるようにするた めのツール u あくまでビルダー。 u satisのダウンロード u 設定ファイルの作成 u ビルド
- 56. u satisのダウンロードもcomposerで u satisディレクトリが作成されて、必要なファ イルが⼀一式落落ちてくる。 u 必要なのは`satis/bin/satis`なので、ここ にパス通しとけばどこにおいてもOK
- 58. u 設定ファイルができたらビルドコマンド を叩いて完了了 u 引数を指定しなかった場合、satis.jsonを ⾒見見に⾏行行く。 u 出⼒力力ディレクトリは引数で与えてもいい し、設定ファイルの`output-dir`で指定し てもいい。
- 66. u satisリポジトリ使えば、Packagistみたいなことがで きる。 u packagistを完全に無効化するときは、利利⽤用する側の composer.jsonで以下のように記述する。 u archiveを使⽤用すれば、github死んでてもなんとかな る。 u satis側のビルドが重い。特に依存関係が”*”とかで書かれ てると全部引っ張ってきてしまう。