Composer は、PEAR パッケージ マネージャーに代わる非常に人気のあるツールです。
ユーザーにとって、Composer は非常に簡単なコマンドで必要なコード パッケージです。がベンダー ディレクトリにダウンロードされると、開発者はパッケージを導入して使用できるようになります
キーは、プロジェクトによって定義された Composer.json にあり、プロジェクトが依存する必要があるパッケージを定義できます (依存パッケージは他のパッケージに依存する場合があります (これはコンポーネントの利点です)。Composer は必要なものをすべて
の定義内にダウンロードします。 Composer はユーザーにとって非常に便利ですが、その背後にある概念はまだ理解する必要があります。Github の急速な発展のおかげで、PHP 言語はますます現代的になり、より高度なものになってきています。 Composer を理解するには、まずその構造を大まかに理解します。
Composer の構造
Composer コマンド ライン ツール:
これを理解するだけであれば、ユーザー定義の Composer.json を通じて必要なコードをダウンロードします。 Composer を簡単に使用して、それをマスターしましょう いくつかの特定のコマンドで十分です
コードローダーの自動読み込み:
Github:
Packagist:
Composer.json:
これは Composer のコアであり、Composer のルールも上で説明したものです。最初に使用するときは注意が必要です。
Composer コマンド ライン ツール
ユーザーは、自分のプロジェクトの下に combos.json を作成してプロジェクトの依存関係パッケージを定義することも、composer init を通じて操作することもできます。
composer install は最も一般的に使用されるコマンドです。Composer は、ダウンロードしたパッケージをローカルの combos.json インストール パッケージに基づいてプロジェクトのベンダー ディレクトリに配置し、同時にパッケージのバージョン情報をインストールします。バージョンをロックするには、composer.lock に入れます。実際、インストール中に、composer.lock のバージョンが現在のベンダー ディレクトリ内のコードのバージョンと一致していることが判明した場合、Composer は何もせず、composer.lock の目的を実行します。 composer update では、パッケージの最新バージョンを入手できるように、composer.lock を更新するにはどうすればよいでしょうか。このコマンドで最新バージョンを更新します composer config パッケージを理解することをお勧めします。グローバル設定は COMPOSER_HOME/config.json に保存され、非グローバル設定情報はプロジェクト ディレクトリに保存されます。 config --list -gcomposer config - g Notice-on-install falsecomposer global config bin-dir --absolutecomposer create-project
このコマンドは一般的には使用されませんが、個人的には依然として非常に重要だと考えています。プロジェクトのすべての依存関係パッケージをダウンロードするための通常のインストール コマンド このプロジェクトのベンダー ディレクトリに移動します。このコマンドは、すべてのコードとその依存パッケージを 1 つのディレクトリに配置します。これは、通常、パッケージ開発者が git clone コマンドを実行するのと同じです。 Command.
composer global
はこれを使用してバグを修正する可能性があります。
これはグローバル インストール コマンドであり、COMPOSER_HOME ディレクトリで Composer コマンド (インストールや更新など) を実行できます。もちろん、COMPOSER_HOME は $PATH 環境にある必要があります。
たとえば、composer global require fabpot/ を実行します。 php-cs-fixer では、php-cs-fixer コマンド ラインをグローバルに実行できるようになりました。後で更新する場合は、コンポーザーを変更するときに、composer global update
composer dump-autoload
を実行するだけです。プロジェクトの下にある json ファイル、いいえ、更新するには必ずコンポーザー更新コマンドを実行してください。たとえば、このコマンドを使用して (packagist からではなく) ローカルのカスタム パッケージを参照することができます。
composer require
composer require cerdic/css-tidy:1.5.2composer require "ywdblog" を手動または対話的に作成する場合は、このコマンドを使用してパッケージをインストールできます。 /phpcomposer:dev-master"
–prefer-source および –prefer-dist パラメーター
–prefer-dist: 安定したパッケージの場合、通常、Composer のインストールではデフォルトでこのパラメーターが使用され、インストールを高速化することもできます。たとえば、実際にインストールせずに、対応するパッケージを packageist から直接インストールすることができます。
–prefer-source: このパラメーターを使用すると、パッケージのインストール後に Github から直接インストールされます。 、ベンダー ディレクトリには .git 情報も含まれます
composer require "ywdblog/phpcomposer:dev-master" --prefer-source
# Vendor/ywdblog/phpcomposer ディレクトリに .git 情報が含まれます追加方法Composer へのプロキシ
Composer のダウンロードは、中国では特に遅くなります 2 つの方法で速度を上げることができます
composer config repo.packagistamper "https://packagist.phpcomposer.com"
edit combos.json
" リポジトリ": { "packagist": { "type": "composer", "url": "https://packagist.phpcomposer.com"
}}
オートローディングコードローダー
composer自体はオートローダーを統合し、 PSR-4、PSR-0、クラスマップ、ファイルの自動ロード。
ここでは、PSR-4 標準に準拠する Composer Reference クラスマップ、ファイル、ローカル コードの使用方法を示す例を示します
composer.json を編集します
"autoload" : { "クラスマップ": ["othsrc/","classsrc.php"]、"ファイル": ["othsrc /filesrc.php"]、"psr-4": {"FooBar": "src"}
}
composer dump-autoload
Composer のオートローダーを使用したくない場合は、直接インクルードすることができますVendor/composer/autoload_*.php ファイルを開き、独自のローダーを設定します。
リポジトリ
リポジトリについては、理解する必要はありませんが、マスターすれば、 Composer については、中国語と英語のドキュメントで詳しく説明されています。
基本概念:
Composer は、いくつかのリソース パッケージとパッケージの説明をインストールします。より重要なメタデータの説明は、dist とsource がアーカイブを指し、ソース パッケージの特定のバージョンのデータがパッケージ化されています。開発中のソース。通常はソース コード リポジトリ (git など) です。
リソース ライブラリ:
リソース ライブラリは、パッケージ/バージョンのリストです。
Composer が参照します。プロジェクトに必要なリソース パッケージを見つけるために定義したすべてのリポジトリ (この文は非常に重要です)
Packagist.org はデフォルトで Composer に登録されています (または Packagist として理解されます。org は Composer リソース ライブラリのデフォルトのウェアハウス タイプです)。 )
Composer リソース ライブラリ タイプ
Composer リソース ライブラリには 4 つのタイプが含まれています。デフォルトは、packagist.org で使用されるリソース タイプである Composer タイプです。
それは 1 つを使用します。packages.json ファイルには、すべてのリソース パッケージ メタデータが含まれています。パッケージを pckagist.org に公開すると、システムはデフォルトで package.json を作成しますが、パッケージに対応するファイルが見つかりませんでした。
VCS リソース ライブラリ タイプ
プライベート Composer プライベートをビルドしたい場合たとえば、プロジェクトのcomposer.jsonで次のように定義すると、Github .
{ "repositories": [ { "タイプ": "vcs"、"url": "https://github.com/ywdblog/phpcomposer" } ], "require": { "ywdblog/phpcomposer": "dev-master" } }
composer update を実行すると、Comoser は実際には、pckagist.org ではなく Github からパッケージをダウンロードします。
さらに、パッケージ リソース ライブラリ タイプまたは PEAR リソース ライブラリ タイプを使用する必要がある場合は、一般的に公式ドキュメントを参照してください。 、composer.json.
Composer.json
Composer.json については、この記事で何度も言及しています。たとえば、サードパーティ パッケージを使用する場合は、Composer がサードパーティ パッケージをインストールした後、composer.json もローカルで定義する必要があります。どちらも、composer.json と呼ばれますが、その違いは何ですか?
プロジェクトの下に combos.json を定義する場合、このパッケージは ROOT パッケージと呼ばれます。このcomposer.jsonは、プロジェクトに必要な条件を定義します(たとえば、プロジェクトはサードパーティのパッケージに依存する可能性があります)。
composer.jsonの一部のプロパティは、ROOTパッケージでのみ使用できます。 config プロパティは ROOT パッケージでのみ有効です。
リソース パッケージは ROOT ですか? たとえば、ywdblog/phpcomposer を git clone する場合、ローカルの phpcomposer ディレクトリは ROOT パッケージになります。ローカルの phpcomposer ディレクトリにある /phpcomposer の場合、プロジェクト phpcomposer は ROOT パッケージになります
Composer-schema.json について学ぶには、この Web サイトを参照してください。Laravel の combos.json 定義は非常に古典的です。パッケージのバージョンについて
ユーザーがローカルでcomposer.jsonを構成する場合、パッケージの特定のバージョンが必要な場合、ComposerはGithubリポジトリからのタグまたはブランチでのパッケージのダウンロードをサポートします
Githubのタグについては、Packagist。 X.Y.Z、vX.Y.Z、X.Y.Z パッケージ タイプに準拠する、対応するパッケージのバージョンを作成します。つまり、Github にはパッケージの特定のバージョンが 1 つだけありますが、Composer は複数の形式の参照メソッドをサポートしています。
composer require monolog/monolog 1.0.0-RC1
composer require monolog/monolog v1.0.0-RC1composer require monolog/monolog 1.0.*
composer require monolog/monolog ~1.10
Github 上のブランチの場合、 Packagist は、ブランチ名がバージョンに似ている場合、{ブランチ名}- が作成されます。ブランチ名がバージョン番号に似ていない場合は、パッケージのバージョン番号が作成されます。 dev-{ブランチ名}の形式のバージョン番号
composer require monolog/monolog master-dev
composer require monolog/monolog master.x -dev
概要:
Composerを理解するには、最も重要なことは練習することです最後に、PSR-4 と名前空間を理解することができます。また、プロジェクトを pckagist.org に公開してみることもできます。
以上がComposer の詳細な紹介の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。