いまさらComposer

@mkkn_info

https://getcomposer.org/

u  Composer = 依存関係管理理ツール u  依存関係 = プロジェクトやライブラリが必要/前提とするライブラリの情報 u  ライブラリをダウンロードして… u  プロジェクトに組み込む u  Include_pathに突っ込む

SOURCE library A library B SOURCE library A library B SOURCE library A library B

SOURCE library A library B SOURCE library A library B SOURCE library A library B ここにもここにもここにも

SOURCE library A library B SOURCE library A library B’ SOURCE library A library B いつの間にかB’に元のverっていくつだっけ…？

u  プロジェクトにライブラリが混⼊入すると u  誰かがライブラリを改変するかもしれない u  バージョン管理理にバージョン管理理したくないコードが混⼊入する。 u  include_pathに組み込むと u  環境構築⾯面倒 u  ライブラリのバージョン管理理は？ u  「基本仕様書 – 依存ライブラリの項を参照…」みたいな

u  PHPの依存関係管理理ツール u  現在のPHPでは事実上の主流流ツール u  composer.jsonに使⽤用ライブラリ(依存関係)を記述 u  composerコマンドで各環境毎にライブラリを調達する

SOURCE composer.json SOURCE composer.json composer.jsonに使⽤用ライブラリを記述して、各環境でダウンロードするスタイル SOURCE composer.json vendor vendor

u  プロジェクトとライブラリを分離離できる。 u  使⽤用ライブラリ情報はcomposer.jsonに記述するだけ u  プロジェクトのバージョン管理理に余計なファイルが⼊入らない。 u  環境ごとにそれぞれでライブラリを調達。 u  バージョン情報も⾃自動的に記録される。 u  ライブラリxxxのバージョンxxxを使⽤用…など

u  COMPOSER実⾏行行環境の準備 u  ライブラリの名前調べる u  プロジェクトに依存関係定義 u  インストール u  ライブラリの利利⽤用

u  composer.phar ファイルさえあればOK u  インストールの必要なし u  プロジェクトファイルに含めとけば、チーム内への頒布/導⼊入も楽 u  composer.pharにパスを通せば、グローバルにも使える。

u  composer.jsonの作成 u  コマンドで対話的に作成可能公開するパッケージでなければ nameとかauthorとかの情報はあんまり厳密に考えなくてもOK

u  COMPOSER経由のインストールは Packagist登録ライブラリを⽤用いるのが楽。 u  コマンドでPakckage名を検索索できる u  vendor_name/package_name u  余⼒力力があれば、バージョン情報も u  PackagistのWEBページでも

https://packagist.org/

u  ライブラリの登録もコマンド経由で u  composer.jsonが⾃自動的に更更新される。 Packagist登録名通常 vendorName/libNameの形式バージョン番号 Gitのブランチやタグが使える。タグ :tagname ブランチ :dev−branchname

u  ライブラリ群のダウンロードもコマンド経由で。関連ファイルが⽣生成される u  composer.lock u  vendor ディレクトリ u  プロジェクトからvendor/autoload.php をrequireすれば完成。

u  ライブラリ群は全てvendorディレクトリにダウンロードされる。 u  ファイル内でvendor/autoload.phpを requireすれば、クラス利利⽤用時に⾃自動でライブラリがロードされる。 u  個々のライブラリ毎にrequire_onceとかする必要なし。 u  フレームワーク組み込み系のComposerはこの辺⾃自動でやってくれてるケースが殆んど。

u  ライブラリの更更新 u  デプロイ

u  installコマンド実⾏行行後でも、requireコマンドでライブラリを追加できる。 u  追加後、lockファイルが更更新される。 u  ライブラリを最新のバージョンに更更新する場合には、updateコマンドを使⽤用する。 u  引数を付けない場合、全てのライブラリが更更新される。 u  更更新とともにcomposer.lockファイルも更更新される。

u  composer.lock ファイルにインストールしたバージョン情報が全て書き出される。 u  dev-master等の曖昧なバージョン情報を解決 u  composer.lockがある環境でinstallコマンドを叩いた場合、ファイルに記載された通りのバージョン情報を再現してくれる。 u  デプロイファイルに含めておけば、開発環境からリリース環境まで同じ状況を再現可能。 u  GITフックにねじ込むとかで⾃自動ライブラリ更更新

u  とりあえず以下の3つをバージョン管理理に含めとく u  composer.phar: みんなで使うComposer u  composer.json: 構成情報 u  composer.lock: バージョン情報 u  vendorはバージョン管理理に含めない u  デプロイ時にデプロイ先環境で composer install 実⾏行行する

u  requireコマンドにdev オプションをつけると通常のrequireエントリとは別の”require- dev”エントリに依存関係が記述される。 u  リリース環境などでは、--no-devオプションを付けてinstall/updateすることで、 require-devエントリの依存関係処理理をスキップできる。

u  多少⾯面倒だが、Packagist経由でないインストールも可能。 u  Packagistで公開しなくても⾃自作ライブラリをComposerで使える!! u  vcs: GITやSVN等のリポジトリ u  pear: pearリポジトリ u  package: ⼒力力技 u  composer: composer リポジトリの追加⾃自分でPackagist以外のComposerリポジトリ⽴立立てる⼈人向け

u  任意のGITリポジトリが利利⽤用可能 u  GIT以外にもSVNとかのURLも使えるらしい。 u  Github,Bitbucket のURLを登録している場合、gitクライアントがなくてもdistでzip形式のダウンロードを実⾏行行してくれる。

u  PEARリポジトリを使⽤用することも可能 vendor名は pear-{channelName} の形式になる

u  ⼒力力技でSmartyも配布先情報は、distか sourceどちらかが必要。両⽅方書いてもいい。 versionは.lockファイルに影響してくるので、記述しておくほうほうがいい。

u  dev-master ってなんよ？ u  → masterブランチのこと u  Composerにおけるバージョンは、基本的に tagとbranch u  tag名はそのままバージョン名になる u  branch名は dev-{ブランチ名}でバージョン名になる。 u  ライブラリ側のcomposer.jsonでversionを指定することもできるが、あまり推奨されていない。

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

u  branchは、dev-{branch名}の形式でバージョンとして利利⽤用できる。 u  dev-master : masterブランチ u  タグの規約に沿った形のブランチ名は、 {ブランチ名}-devがバージョン名になる。 u  2.0.x-dev : 2.0ブランチまたは2.0.x ブランチ u  ブランチのバージョンは開発バージョンとして解釈される。

u  バージョンに別名をつける。 u  ⾃自⾝身のdev-masterに1.0.x-dev相当のバージョンを付与する。 u  例例えば、バグフィックスをフォークリポジトリで取ってくるときとかに。

u  依存関係定義時に、バージョンを指定。 u  バージョンを調べるのは⾯面倒。 u  毎回dev-masterじゃいかんの？ u  バージョン指定してcomposer.json作るならlockファイルとかいらなくね？

u  requireでバージョン指定していれば、 composer.lockは不不要？ u  下位のライブラリの依存関係周りで詰む lib A lib B lib C require libB:2.0.0 require libC:dev-master

u  composer.lockがあれば、requireは基本 dev-masterでOK？ u  安定版ソースでもsource扱いになってしまう。 u  composer update しないなら問題ないんじゃない？ u  dev-masterは⼀一応開発版バージョン。 minimum-stability周りに引っかかると厄介。

u  requireコマンド実⾏行行時にもちゃんとバージョン指定した⽅方がいい。 u  その上で.lockファイルも適切切に配布して、デプロイ先でのinstallコマンドで開発環境のバージョンを再現する。

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が依存するライブラリ群のバージョン指定

u  ext-hogeのせいでライブラリが導⼊入できない時には、とりあえずprovideエントリを追加することでエラーを回避できる模様。

u  dist: .git ついてこない。 u  source: .git ついてくる。 u  --prefer-dist,--prefer-source オプションで動作を強制できる。 u  デフォルトでは、安定版のダウンロードは dist、開発版のダウンロードはsourceとなるよう。 u  dev-masterはブランチバージョン指定なので開発版扱いでsourceがデフォルトとなる u  1.0.0はタグバージョン指定なので、安定版扱いでdistがデフォルトとなる。

u  requireの戻り値でオブジェクト受け取れる。 u  ComposerAutoloadClassLoaderクラスのインスタンス u  require後にクラスマップやPSR系の設定追加ができる(動的オートローダ)。 u  Composerだけでマイクロフレームワークっぽいの作るときとかに。

u  satis : composer リポジトリビルダー u  packagist的なComposerリポジトリを⾃自分で作成してホスティングできるようにするためのツール u  あくまでビルダー。 u  satisのダウンロード u  設定ファイルの作成 u  ビルド

u  satisのダウンロードもcomposerで u  satisディレクトリが作成されて、必要なファイルが⼀一式落落ちてくる。 u  必要なのは`satis/bin/satis`なので、ここにパス通しとけばどこにおいてもOK

u  設定ファイルを作成。デフォルトの名前は`satis.json`。

u  設定ファイルができたらビルドコマンドを叩いて完了了 u  引数を指定しなかった場合、satis.jsonを⾒見見に⾏行行く。 u  出⼒力力ディレクトリは引数で与えてもいいし、設定ファイルの`output-dir`で指定してもいい。

u  ビルドするとhtmlファイルとjsonファイルができるのでapacheなりnginxなりPHPサーバなりで適当に公開すればOK。 u  satisリポジトリを利利⽤用する側のcomposer.jsonにリポジトリを登録すれば完了了。

デザインはシンプルだけど、 jsで⾮非同期にパッケージリスト更更新してくれるなど地味に⾼高機能

repositories: ビルド時に⾒見見に⾏行行くリポジトリ require: ⾒見見に⾏行行ったリポジトリから取ってくるパッケージ require-dependencies: 依存パッケージが依存するパッケージまで取ってくるならtrue もちろんrequire-dev- dependenciesというのもある

require-all: repositoriesに記述したリポジトリに存在する全てのパッケージを記録する。 packagistとか登録しながらこれやるとすげぇ重い

ローカルGITだって参照できる。optionエントリで、SSH認証とかもなんか通せるらしい。 https://getcomposer.org/doc/articles/handling- private-packages-with-satis.md#security

archive: ビルド時にソースをダウンロードしてくれる。

name: HTMLページの名前 homepage: HTMLに表⽰示するURL twig-template: HTMLで使⽤用するtwig output-html: falseでHTMLを⽣生成しない。

u  satisリポジトリ使えば、Packagistみたいなことができる。 u  packagistを完全に無効化するときは、利利⽤用する側の composer.jsonで以下のように記述する。 u  archiveを使⽤用すれば、github死んでてもなんとかなる。 u  satis側のビルドが重い。特に依存関係が”*”とかで書かれてると全部引っ張ってきてしまう。

Packagist への登録⽅方法がスクリーンショット付きでわかりやすく掲載されています。

いまさらComposer

by Mika Kane

on Jun 19, 2014

Statistics

Views

Actions

2 Embeds 2

Accessibility

Categories

Upload Details

Usage Rights

Report content

いまさらComposer Presentation Transcript