composer周りメモ
- composerとは?
- 用語
- composerのインストール
- dockerでのcomposerのインストール
- composerの使い方
- composer利用する上での検討事項
- composer昔話
- composerの恩恵
composerとは?
ドキュメントでは以下のように説明されてる。
ComposerはPHPでの依存関係を管理するツールの一つです。
Composer is a tool for dependency management in PHP.
ComposerはYumやAptのようなパッケージマネージャーではない。パッケージやライブラリを扱うが、プロジェクトごとにそれらを管理し、プロジェクトの内のディレクトリ(vedor
ディレクトリとか)にインストールする。デフォルトでは、グローバル環境には何もインストールしない。だから、依存関係を管理するツールである。便宜上、グローバルコマンドを利用することでグローバルプロジェクトもサポートしてます。
Composer is not a package manager in the same sense as Yum or Apt are. Yes, it deals with "packages" or libraries, but it manages them on a per-project basis, installing them in a directory (e.g. vendor) inside your project. By default, it does not install anything globally. Thus, it is a dependency manager. It does however support a "global" project for convenience via the global command.
composerが有益であるのは以下の要求がある時。
- 開発中プロジェクトが複数のライブラリ、パッケージに依存している
- そのライブラリ、パッケージの一部が他のライブラリに依存している
上記の要求をcomposerにインストール対象を指定することで、依存関係の解決などを行なってくれる。
composerのインストール
最新のcomposerを利用したい場合、PHPが7.2.5以上が必要。(composerの2.2系ではPHP5系にも対応しているらしい)
下記リンクに従ってcomposerの実行ファイル(.phar)をダウンロードする。
pharファイルとは
ダウンロードすると作業ディレクトリにcomposer.pharが用意されるだけなので、呼び出しやすいようにする。
方法は2つあり、今回はパスが通ってる場所に移動させる。(グローバルに利用したいか、特定ディレクトリ下で利用したいかも考えておく、自分はグローバルに利用する)
- composer.pharをパスが通ってる場所に移動する
- composer.pharがあるディレクトリにパスを通す
下記ドキュメント通りにmvすると、$ comoser
で呼び出せる。
dockerでのcomposerのインストール
dockerのマルチステージビルドを利用することで簡単に、composerの最新バージョンを追従することができる。
→プロダクションコードでは、"正常に"動作するものをデプロイしたいので、思わぬところでコケないためにもlatest
ではなくバージョン指定が望ましいと思ってる。(経験浅いのでcomposerの最新を追従したいというシステム要求のシチュエーションがあんまり分からない、最新composerの機能テスト、パフォーマンス、バグ修正、セキュリティ対策とか?)
COPY --from=composer:latest /usr/bin/composer /usr/bin/composer
※マルチステージビルドの利用にはdockerのバージョンが17.05以上である必要がある
composerがもたらす恩恵
先ほど、composerは依存関係を管理しながら外部ライブラリのインストールを楽にしてくれるものだと書いたが、それだけではなく以下の恩恵も受けることができる。
Composerはライブラリを含めた依存性をまとめてインストールしてくれるだけではなく、PHPが本来持つクラスのオートローディングの仕組みを使って、自前のコードとライブラリのコードを自然に統合してくれることにあります。
composer昔話
昔、というかcomposer 1系ではインストールに時間がかかるので、速くするプラグイン、ミラーサイトとかが用意されていた。
現行の2系ではパフォーマンスについてcurlの並行処理をデフォルトで利用するようになっており、それらはあまり心配なくなったらしい?
用語
<パッケージ>
composerで管理をする対象のこと。リポジトリに公開されていなくても、comopserの管理対象はパッケージと呼ぶ。
以下のドキュメントでは以下のように書いてある。
パッケージとは何かを含むディレクトリであり、composerではPHPコードのまとまりであれば何でもパッケージになり得る、的なニュアンス
Composer is a dependency manager. It installs packages locally. A package is essentially a directory containing something. In this case it is PHP code, but in theory it could be anything. And it contains a package description which has a name and a version. The name and the version are used to identify the package.
In fact, internally Composer sees every version as a separate package. While this distinction does not matter when you are using Composer, it's quite important when you want to change it.
<リポジトリ>
パッケージの源流となるもの。パッケージをまとめ、そこからcomposerは指定されたパッケージを探しインストールを行う。デフォルトで登録されているリポジトリはPackagistだけだが、自分で追加可能。
A repository is a package source. It's a list of packages/versions. Composer will look in all your repositories to find the packages your project requires.
By default, only the Packagist.org repository is registered in Composer. You can add more repositories to your project by declaring them in composer.json.
<バージョン>
パッケージのバージョンを表す。通常セマンティックバージョニングが利用される
<Packagist>
デフォルトで有効になっているリポジトリ
Packagist is the main Composer repository. It aggregates public PHP packages installable with Composer.
<PEAR>
Composerが主流になる前に利用されていた依存関係管理ツール
composerの使い方
-
--prefer-dist
オプションはzip形式でダウンロードするためのもの、一般的にこのオプションつけた方が高速-
git clone
じゃなくて、wgetでzipファイルをダウンロードしてるらしい
-
composerベストプラクティス
- config.platform項目の利用
- 依存関係の情報を固定化することができる
- composer updateしてplatformに設定したバージョンのライブラリがインストールされる
- composer.lockをgit管理対象にする
- composerダウンロード時のログを綺麗に保つ
-
--no-progress
オプションの利用
-
- オートローダーの高速化
- composerの各コマンドで
--optimize-autoloader
オプションの利用
- composerの各コマンドで
- なんでこのパッケージ入ってるんだっけ?
-
composer why package
、なぜそのパッケージがインストールされてるか -
composer why-not package
、なぜそのパッケージがインストールされてないか
-
- 新しいバージョンを調べる
composer outdated
- パッケージを高速にインストールする
-
--prefer-dist
オプションを利用する - アクセストークンとか認証情報の設定ができてないとうまく動かないケースあり
- zip形式でダウンロードする
- パッケージごとに指定可能
-
config.preferd-install
で設定することもできる
-
-
- type=pathリポジトリ
- 巨大化したリポジトリを仮想的に分離する
require、includeの違い。
require、require_onceの違い。
まとめ
- 外部ファイルをあるスクリプト内で利用したい場合require、includeを使う
- アプリケーション、ソフトウェアのコアな部分の読み込みはrequire、それ以外はinclude
- 外部ファイルの内容を使用時に再読み込みが必要ない場合はonceで読み込む
composer create-project
はgit clone
してcomposer install
してるのと一緒。
composerはrootユーザーで実行するのは非推奨。
Certain Composer commands, including
exec
,install
, andupdate
allow third party code to execute on your system. This is from its "plugins" and "scripts" features. Plugins and scripts have full access to the user account which runs Composer. For this reason, it is strongly advised to avoid running Composer as super-user/root. All commands also dispatch events which can be caught by plugins so unless explicitly disabled installed plugins will be loaded/executed by every Composer command.