PHP Manual

サーバー管理

Composer - 高度な機能の完全な概要

2020-03-10T19:18:19.000Z

Jan Barášek

Obsah článku

すでにご存知のように、ComposerはPHP用の堅牢なパッケージおよび依存性マネージャで、これを通じて何百ものプロジェクトを同時にエレガントに管理し、一度記述したコードをすべてのアプリケーションに同時に配布することが可能です。

このチュートリアルは、詳細で包括的な開発者向けガイドとして機能します。Composerで作業するための重要な上級テクニックをすべて網羅し、技術的な詳細や関連する依存関係についても説明します。

Composerのインストール

プラットフォームに関係なく、Composer公式サイトからダウンロードします。

内部では、PHPファイル composer-setup.php がダウンロードされ、これをCLIモードで実行するとComposerをインストールすることができます。また、ComposerはPHPがないと動作しないので、まずコンピュータでPHPが動作していることを確認します（ターミナルで利用可能であればよい）。

MacとLinuxでは、Composerはインストール後すぐに動作し、composer -v コマンドを呼び出すだけで、Composerが正しくインストールされているかどうかをすぐに確認することができます。

Linuxでは、次のコマンドでインストールできます。 /usr/bin/php -r "copy('https://getcomposer.org/installer', 'composer-setup.php');".

Windowsでは、Git Bash for Windowsというツールをインストールすると、Linuxとほぼ同じ動作をする特定のターミナルを開き、Linuxと同じ環境で作業することができます。

サーバーへのインストールは、ローカル環境と同じです。Composerが内部で使用するPHPのバージョンが正しいことを確認するだけです。

使用可能なコマンド

Composerには様々なコマンドが実装されています。

使い方は、composer <command> で、例えば、composer update とします。

1.10.0`の概要です。

| コマンド｜説明｜意味
|-----------------------|----------------|
| 概要｜Composerに関する簡単な情報を表示します。
| archive | 選択されたコンポーザー・パッケージの内容でアーカイブを作成します。
| browse | 選択したパッケージや作者などの関連するホームページをウェブブラウザで開きます。多くの場合、その使用方法に関する文書が含まれていることがあります。
| cc | 過去にダウンロードされたパッケージのバージョンで、Composer内部のキャッシュをクリアします。
| check-platform-reqs | 現在のプラットフォームのインストール要件が満たされているかどうかをチェックします。
| clear-cache ｜ Composerの内部キャッシュをクリアします。
| clearcache ｜ Composerの内部キャッシュをクリアします。
| | config ｜コンフィギュレーションディレクティブを設定します。
| create-project ｜選択したパッケージをもとに新しいプロジェクトを作成し、そのプロジェクトを配置するためのフォルダを自動的に作成します。
| depends｜選択したパッケージがどのような原因でインストールされたかを表示します。
| diagnose ｜一般的なエラーを特定するためにシステムを診断します。出力の加工は開発者次第、あくまでリストアップです。
| dump-autoload| 新しい <a href="/autoloading-trid">autoloader</a> を生成します。 |dumpautoload｜新しい <a href="/autoloading-trid">autoloader</a> を生成します。 |exec｜ベンダーのバイナリやスクリプトを実行する。 |exec｜ベンダーのバイナリやスクリプトを実行する。 |fund｜依存関係の作り方・変え方を探る。 | $COMPOSER_HOME 変数からグローバルな Composer のコマンドを実行できるようにします。
| | help ｜コマンドのヘルプを表示します。
| home | ブラウザで特定のパッケージのホームページを開きます。
| i|composer.lockファイルが存在し、それが有効であれば、それにしたがってすべてのプロジェクトの依存関係をインストールします。問題がある場合は、composer.jsonの情報が使われ、composer.lockは元の状態に戻される|。 |info| プロジェクトに現在インストールされているパッケージの情報を表示します。すべてのパッケージの名前、現在のバージョン、簡単な説明を表示します。 |init| カレントディレクトリに基本的なcomposer.json関数を作成します。 |install|composer.lockファイルが存在し、有効であれば、それに従ってすべてのプロジェクトの依存関係をインストールします。問題が発生した場合は、composer.jsonの情報が使われ、composer.lockは元の状態に戻される|。 |licenses| すべてのパッケージとそのバージョン、現在のライセンスの一覧を表示します。 | リスト｜利用可能なコマンドのリストを表示します。 | |outdated｜新しいバージョンがインストール可能で、依存関係を満たしているすべてのパッケージの一覧を表示します。各パッケージには、Composerがインストールを推奨する最新の互換バージョンが表示されます。 |prohibits| どのパッケージと依存関係が要求されたパッケージやバージョンのインストールを妨げるかを表示します。 |remove|requireまたはrequire-devコンフィギュレーションセクションからパッケージを削除します。 |require| 要求されたパッケージをcomposer.jsonに追加し、インストールする。依存関係を満たすことができない場合は、元の状態に戻ります。 |run|composer.jsonで定義されたスクリプトを実行します。 |run-script|composer.jsonで定義されたスクリプトを実行します。 |search｜キーワードや検索クエリでパッケージを検索します。 |self-update| 内部のcomposer.pharを最新バージョンに更新します。 |selfupdate| 内部のcomposer.pharを最新バージョンに更新します。 | |show｜現在インストールされているパッケージの詳細情報を表示します。 |status| 手動でパッケージに加えられたローカルな変更の概要を、元々インストールされていたパッケージのソースとの比較に基づいて表示します |。 |suggests| パッケージの候補を表示します。提案には、セキュリティアップデートのインストールなど、さまざまな種類のアクションが含まれます。 |update| 依存関係に従ってプロジェクト全体を更新し、常にcomposer.jsonによってすべての依存関係を満たすようにします。成功すればcomposer.lockを更新し、そこに現在インストールされているバージョンを書き込む。 |upgrade|updateへのエイリアス。 | u｜「update」のエイリアスです。
| validate ｜ composer.jsonとcomposer.lockに構文エラーがないかチェックします。 |why| 現在選択されているパッケージが、すべての依存関係を含めて、どのパッケージによってインストールされたかを表示します。 |why-not` | 選択したパッケージやバージョンのインストールを妨げるパッケージやバージョンを表示します。

プロジェクトの作成と定義

Composerで管理される各プロジェクトは、そのルートにあるすべての依存関係を定義した composer.json ファイルによって定義されます。このファイルは、既存のプロジェクトに対して手動で作成することも、プロジェクト作成時に自動的に作成することも可能です。

Composerではすべてがパッケージなので、プロジェクト自体もパッケージをベースにすることができます。ですから、例えば、非常によく似たプロジェクトを何十何百と作成する場合、それらの基本構成と構造を別のパッケージに入れ、それをベースにインストールすることは理にかなっています。

そのようなパッケージの例として、私のBaraja Sandbox があります。これは純粋な Nette 3.0 をベースに、私の Package Manager に基本的な依存関係を追加したもので、Nette 構成におけるすべてのプロジェクトと依存関係管理に使用します。

そして、サンドボックスのインストールは、コマンドで簡単に行えます。

$ composer create-project baraja/sandbox <your-project-name>

プロジェクト名に基づいて、Composerは自動的にプロジェクトをインストールするためのフォルダを作成します（パッケージの内容をコピーし、依存関係をインストールします）。

Vendor` フォルダでは、Composer がすべてのパッケージを管理し (物理的なファイルはそこにあります)、クラスのオートロードを生成します。

require __DIR__ . '/vendor/autoload.php';
// アプリケーションのコードそのもの

追加パッケージと依存パッケージのインストール

機能的なプロジェクトでは、新しいパッケージをインストールしたり、依存関係を追加することが非常に簡単にできます。

その方法は2つあります。

composer require …` コマンドを使用します。
composer.jsonファイルのrequireセクションに直接依存関係を追加し、composer update` コマンドを使用します。

例えば PackageManager: composer require baraja-core/package-manager や Doctrine: composer require baraja-core/doctrine をインストールしてみてください。

選択したパッケージがインストールできない場合、具体的な理由を尋ねることができ、Composerはこれを妨げる依存関係をリストアップします。多くの場合、特定のバージョンへの依存関係を修正したり、互換性のないコードを削除したりするだけで十分です。詳細については、composer why baraja-core/doctrine というコマンドを使用してください。

プロジェクトやパッケージの更新

よく設計されたプロジェクトは、時間の経過とともに簡単にアップデートをダウンロードでき、常にすべてのパッケージの最新バージョンを持つことができるように開発されています。主な利点は、すべてのバグが修正され、多くの場合、パフォーマンスが向上し、多くの新機能を利用できることです。また、徐々に切り替えていくことで、規模が小さくてもその場で問題を解決し、非互換性を回避できるため、久しぶりのアップデートでも煩わしさを感じません。

すべてのパッケージと依存関係を更新するには、composer update コマンドを使用します。

場合によっては、アップデート処理そのものに失敗することがあります。その理由は、通常、依存関係が壊れているか、互換性のないパッケージのどちらかです。

パッケージがインストールできない理由の詳細については、composer why-not baraja-core/doctrine というコマンドを使用してください。すでにパッケージがあり、特定のバージョンだけが動作しない (インストールしようとしない) 場合は、特定のバージョンを要求することもできます: composer why-not baraja-core/doctrine:v1.0.20.

composer.json ファイル内では、特定のランタイムへの依存関係をリストアップすることもできます。特に、複数人で開発していて、すべての拡張機能がインストールされているかどうかを確認したい場合に有効です。

通常、PHP のバージョンがチェックされます (7.1.0 以降である必要があります)。

{
"require": {
"php": ">=7.1.0"
}
}

他のシステム拡張の可能性もある。

{
"require": {
"php": ">=7.1.0",
"ext-json": "*",
"ext-session": "*",
"ext-PDO": "*"
}
}

これらのルールは、パッケージやアップグレードをインストールする際に考慮されます。これにより、実行時に明らかになるような問題を防ぐことができます。典型的な例として、決済ゲートウェイのパッケージは API と通信する必要があるので、 curl と json 拡張の依存性を認めなければなりません。

依存関係のトラブルシューティング

多くの場合、依存性違反は PHP のバージョンが悪いために発生します。この場合、Composerは「あなたのPHPバージョン（7.3.11）は "config.platform.php "のバージョン（7.1）で上書きされ、その要件を満たしていません」といったメッセージを投げかけます。

非常に多くの場合、プロジェクトの composer.json に直接設定されている、以下のセクションがエラーの原因です。

"config": {
"platform": {
"php": "7.2"
}
}

変更は、ファイル内で直接行う必要があります。グローバルプロジェクト（インストール前、またはグローバルな依存関係がある）の場合、composer config -g platform.php 7.2.14 でComposerのバージョンを強制することができます（gスイッチは global の意味です）。

場合によっては、最新のパッケージバージョンをインストールし、ローカル環境の設定を無視したいこともあります。この場合、アドバンストコマンドを使用することができます。

$ composer update --ignore-platform-reqs

ignore-platform-reqs` スイッチは自己責任で使用してください、プロジェクトに損害を与えるかもしれません！ 結果を理解していない場合は、使用しないでください。

マニュアルコンポーザーの呼び出し、パラメーター、メモリー管理

Composerは、実際には、いわゆるPHARに包まれたPHPスクリプトです。この情報を知ることで、例えば呼び出し自体のパラメータをより適切に設定できるなど、有効活用することができる。

大規模なプロジェクトでは、RAMが足りなくなり、さらに多くのRAMを割り当てたり、スクリプトの処理時間を増やさなければならないことがあります。

例えば、Windowsでは、このコマンドでできます。

$ php -d memory_limit=-1 C:/xampp/htdocs/composer.phar update

memory_limit=-1` スイッチは、Composer が RAM の制限に影響されず、必要なだけメモリーを消費するように指示します。

Composerアクション後のカスタムユーザースクリプト

Composerアクションを実行した後、ユーザー定義のスクリプトの自動実行を呼び出して、プロジェクトに対して特定のアクションを実行したり、デプロイ後に設定を生成したりすることができます。私は主にローカルサーバーでこの方法を使い、データベースの自動構成ツールを提供し、データベーススキーマを生成するなどしています。

必要なスクリプトを composer.json の scripts セクションに登録する。

"scripts": {
"post-autoload-dump": "Baraja\\PackageManager\\PackageRegistrator::composerPostAutoloadDump"
}

この場合、クラス BarajaPackageManagerPackageRegistrator にあるスタティックメソッド composerPostAutoloadDump が自動的に呼び出されます。Composer は、autoloader クラスの生成を最初に実行したため、このクラスが利用可能です。

Composerで不要な操作をせず、スクリプトを実行するだけなら、composer dumpコマンドは非常に便利です。新しいオートローダー（常に最新の状態に保つことをお勧めします）を生成するだけで、すぐにスクリプトを実行することができます。スクリプトを使ってみたいという方には、ネットフレームワーク用のスマートスクリプトと対話型インターフェースを実装した既成のパッケージBaraja PackageManagerを用意しましたので、ご利用ください。

VendorをGitにバージョン管理？

開発者とよく議論になるのは、vendorフォルダの内容をGitにバージョン管理するか、それともインストールごとに再作成するかということです。

一般的には、コンテンツのバージョンアップを一切行わず、毎回すべてをインストールするのが、よりクリーンな解決策と思われます。しかし、現実には、開発者がパッケージの開発を中止したり、完全に削除したりすることがあります。また、常にパッケージをダウンロードするため、ローカルインストールやアップデートが複雑になり、デプロイが遅くなるほか、新しいバージョンのパッケージが誤ってダウンロードされた場合、短期間のサイト停止を引き起こすこともあります。

私は、ヴェンダーの停止は「セキュリティ」の一種だと考えています。ファイルが物理的にバージョン管理システムにあれば、少なくとも本番サーバー上では、パッケージが動作し、そのコードがローカルに実行されているインストールと全く同じであるという初歩的な保証を得ることができます。また、Vendorは数MB単位で使用することが多く、現在のディスク容量を考えると、作業サイトを保証する価値があることは間違いないでしょう。

** Practical note:** 私が管理している平均的なサイトでは、vendorは30MB以下しか使用しません。これは、Gitにとって許容範囲内の容量です。ジュニアと一緒にリポジトリをクローンする場合、サイトの立ち上げ方をトレーニングする必要はなく、すぐに動作するようになりました。

カスタムコンポーザーパッケージ

Composer内では、一般公開（Packagistで登録）または非公開（Satisなど独自のパッケージサーバーが必要）で、独自のパッケージを作成することができます。

パッケージの作成、維持、開発、バージョン管理の問題は非常に複雑なので、別の記事で紹介する予定です。

とりあえず、【Semantic Versioning】(https://semver.org/lang/cs/)の記事を翻訳しておきましたので、読んでみてください。

Jan Barášek Více o autorovi

Autor článku pracuje jako seniorní vývojář a software architekt v Praze. Navrhuje a spravuje velké webové aplikace, které znáte a používáte. Od roku 2009 nabral bohaté zkušenosti, které tímto webem předává dál.

Rád vám pomůžu: