Composer使い方チュートリアル（基本的な使い方）

Composer は PHP の依存関係管理ツールです。これを使用すると、1 つのコマンドを使用して他の優れたコードをプロジェクトに簡単に参照できます。以下の composer 使い方チュートリアル コラムでは Composer の基本的な使い方を説明しますので、困っている友人の参考になれば幸いです。

#基本的な使い方

はじめに

基本的な使い方を紹介し、monologをインストールしていきます。 /monolog ログ ライブラリを例として挙げます。例:

注: わかりやすくするために、

Composer がローカルにインストールされていると仮定します。

composer.json: プロジェクト設定

プロジェクトで Composer を使用するには、composer.json ファイルが必要です。このファイルには、プロジェクトの依存関係とその他のメタデータが記述されます。

require key

最初に (通常はこれだけ) 行う必要があるのは、composer.json ファイルで require キーを定義することです。プロジェクトがどのパッケージに依存しているかを Composer に簡単に伝える必要があります。

{
    "require": {
        "monolog/monolog": "1.0.*"
    }
}

上記のように、require は、バージョン制約 (1.0.* など) にマップされたパッケージ名 (monolog/monolog など) を持つ json オブジェクトを取得します。

Composer は、この情報を使用して、Composer.json に登録したリポジトリ キーで指定されたバージョン リポジトリ、または Packagist のデフォルトのパッケージ リポジトリで適切なファイルを検索します。上記の例では、composer.json ファイルに他のリポジトリ情報が登録されていないため、monolog/monolog パッケージがデフォルトで Packagist にあると想定されます。 (Packagist の詳細については、以下を参照するか、こちらを参照してください。

パッケージ名

パッケージ名は、ベンダー名とプロジェクト名で構成されます。通常、これらの名前が同じ場合、ベンダー名の存在により名前の競合が解決されます。たとえば、2 人の異なる人が同じ Json という名前のライブラリを作成できます。igorw/json および seldaek/json という名前を付けることができます。

ここでは、パッケージの公開とパッケージの名前付けについて詳しく読むことができます。

##「プラットフォーム パッケージ」を依存関係として指定することもできることに注意してください。これにより、サーバー ソフトウェアの一部のバージョンをカスタマイズできます。以下のプラットフォーム ソフトウェア パッケージを参照してください。

パッケージ バージョンの制約

上記の例では、導入したモノログ バージョンは 1.0.* として指定されていました。これは、すべての開発ブランチが開始されることを意味します。 1.0 以降は、1.0 以上 1.1 未満のバージョンと一致します。

バージョン、バージョン間の関係、またはバージョン管理の方法についての詳細については、こちらをお読みください。

Composer はどのようにして正しいファイルをダウンロードしますか? combos.json で依存関係を指定すると、Composer はまず要求したパッケージの名前を取得し、ライブラリ キーで登録されているリポジトリ内でそのパッケージを検索します。追加のリポジトリが登録されていない場合、または指定したリポジトリ内にその名前のパッケージが見つからない場合は、Packagist に戻ります (詳細は後述)。指定されたパッケージのリポジトリでパッケージが見つかると、パッケージの VCS (つまり、ブランチとタグ) のバージョン管理機能を使用して、指定したバージョン制約に最も一致するものを見つけようとします。バージョンとパッケージ宣言に関する記事を必ずお読みください。 .

注: パッケージを取得しようとして Composer がパッケージの安定性に関するエラーをスローした場合、指定したバージョンはデフォルトの最小安定性要件を満たしていない可能性があります。デフォルトでは、安定したバージョンは検索時にのみ考慮されます。 VCS の有効なパッケージ バージョン。

DEV、アルファ、ベータ、または RC バージョンも取得したい場合。安定フラグと最小安定性キーの詳細については、スキーマ ページを参照してください。

依存関係のインストール

インストール コマンドを使用して、プロジェクトに定義された依存関係をインストールします

php composer.phar install

このコマンドを実行すると、状況に応じて次の 2 つの方法のいずれかで Composer がインストールされます。

composer.lock 以外のインストール

これまでにコマンドを実行したことがない場合は、実行されません。composer.lock ファイルが表示されると、Composer は依存関係のみを解析します。コンポーザー.json ファイルにリストされているものを選択し、最新バージョンをプロジェクトのベンダー ディレクトリにダウンロードします (ベンダーは、すべてのサードパーティ コードが保存されているプロジェクト内の通常のディレクトリです)。上記の例では、すべての Monolog ソース ファイルが Vendor/monolog/monolog/ ディレクトリに置かれることになります。 Monolog に依存関係がある場合は、vendor/.

ヒント:

プロジェクトで git を使用している場合は、vendor を .gitignore に追加することもできます。すべてのサードパーティのパッケージをリポジトリに追加するのは愚かに思えるからです。

Composer はインストールが完了すると、ダウンロードされたすべてのパッケージと正確なバージョン情報を Composer.lock ファイルに書き込み、プロジェクト内のサードパーティ パッケージのバージョンをロックします。プロジェクトのすべてのメンバーが同じバージョンの依存関係にロックされるように、composer.lock をプロジェクト リポジトリに配置する必要があります。

composer.lock ファイルを使用してインストールします。

这里来到了第二种安装方式。如果你在运行 composer install 命令之前已经存在了 composer.lock 和 composer.json 文件， 这意味着你之前使用了 install 命令， 或者项目中的其他成员使用了 install 命令并将 composer.lock 文件提交至了项目中 (这是非常好的)。

无论使用哪种方式，存在 composer.lock 文件时使用 install 命令安装依赖时 composer.lock 都会解析并安装你在 composer.json 中所列出来的依赖，但是 Composer 会严格使用 composer.lock 文件列出来的版本来确保项目中的所有成员所安装的版本都是一致的。因此，你可以获得 composer.json 文件列出的所有文件，但是与此同时他们可能并不是最新的可用版本 (一些在 composer.lock 文件中列出的依赖可能会在这个文件创建之后释放了新的版本)。这个是设计上的，这样的设计可以确保你的项目不会因为一些依赖的改变而崩溃。

提交你的 composer.lock 文件至版本控制工具

将此文件提交至 VC 是非常重要的。因为它可以确保项目中的任何人使用的都是与你是完全一致的依赖。 你的 CI 服务器，生产服务器，团队的其他开发人员，所有人都使用的是相同的依赖项，这减轻了仅部署某些部分而引起错误的可能性。即使你独立开发，在你重新安装项目的 6 个月内，你的依赖项发布了许多新的版本，你依然可以确信你的依赖项是可用的。(请参阅下边有关使用 update 的命令。)

更新依赖到最新版本

如上所述，composer.lock 文件将阻止你自动获取最新依赖版本。如果要更新依赖到最新版本，使用 update 命令。这将获取最新匹配的版本（根据你的 composer.json 文件）并将新版本更新到 composer.lock 文件。（这相当于删除 composer.lock 文件并再次运行 install）。

php composer.phar update

注意：当执行 install 命令时，由于 composer.json 的更改可能影响到依赖解析而未更新 composer.lock ，Composer 将显示警告。

如果只是想安装或更新一个依赖，可以将它们列出来：

php composer.phar update monolog/monolog [...]

注意：对于库来说，没必要提交 composer.lock 文件，请参考：库 - 锁文件。

Packagist

Packagist 是 Composer 的主要资源库。一个 Composer 库基本上是一个包的源：一个你可以得到包的地方。

Packagist 的目标是成为一个任何人都可以使用的中央仓库。这意味着你可以 require 那里的任何包，无需指定 Composer 查找包的位置。

当你访问 Packagist 网站 (packagist.org)，你可以浏览和搜索包。

建议使用 Composer 的开源项目在 Packagist 上发布包。虽然并不一定需要发布在 Packagist 上来被 Composer 使用，但是它能被其它的开发者更快的发现和采用。

平台包

Composer 将那些已经安装在系统上，但并不是由 Composer 安装的包视为虚拟的平台包。这包括 PHP 本身、PHP 扩展和一些系统库。

php 代表使用的 PHP 版本要求，允许你应用限制，例如 ^7.1 。如果需要 64 位版本的 PHP， 你可以使用 php-64bit 进行限制。

hhvm 代表 HHVM 运行环境的版本，并且允许你应用限制 ，例如，^2.3。

ext- 允许你依赖 PHP 扩展（包括核心扩展）。通常 PHP 拓展的版本可以是不一致的，将它们的版本约束为 * 是一个不错的主意。一个 PHP 扩展包的例子是：ext-gd。

lib- 允许对 PHP 库的版本进行限制。以下可用例子： curl， iconv， icu，libxml，openssl， pcre， uuid， xsl。

你可以使用命令 show --platform 去获取你本地可用的平台包。

自动加载

为了描述包的自动加载信息， Composer 会生成一个 vendor/autoload.php 文件，你可以简单的 include 这个文件，并在无需其它额外工作的情况下就可以使用这些包所提供的类：

require __DIR__ . '/vendor/autoload.php';
$log = new Monolog\Logger('name');
$log->pushHandler(new Monolog\Handler\StreamHandler('app.log', Monolog\Logger::WARNING));
$log->addWarning('Foo');

你甚至可以在 composer.json 中添加一个 autoload 指令，来添加自己的自动加载声明

{
    "autoload": {
        "psr-4": {"Acme\\": "src/"}
    }
}

Composer 会为 Acme 命名空间注册一个 PSR-4 的自动加载.

你定义一个命名空间指向目录的映射。 在 vendor 目录同级的 src 目录将成为你项目的根目录。一个案例，文件名 src/Foo.php 需包含 AcmeFoo 类。

添加 autoload 指令之后，你必需重新运行 dump-autoload 来重新生成 vendor/autoload.php 文件。

包含此文件后也可以接收到一个 autoloader 实例，由因此您可以将 include 调用的返回值存储在变量中并添加更多名称空间，这在测试套件中将会很有用，例如：

$loader = require DIR . '/vendor/autoload.php';
$loader->addPsr4('Acme\Test\', __DIR__);

作为 PSR-4 自动加载规范的补充，Composer 也支持 PSR-0、类表、文件清单的自动加载方式。具体请查询 autoload 引用。

你也可以查阅 optimizing the autoloader 了解关于自动加载器的优化.

注意：

Composer 提供自己的加载器，但如果你不想使用那个而想自己配置加载器的话，你可以试试 include vendor/composer/autoload_*.php 这些文件所返回的关联数组来实现。

以上がComposer使い方チュートリアル（基本的な使い方）の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。