Detaillierte Einführung in Composer

Composer ist ein sehr beliebtes PHP-Paketabhängigkeitsmanagement-Tool. Es ist für PHP-Entwickler erforderlich, Composer zu beherrschen Paket mit einem einfachen Befehl in das Herstellerverzeichnis kopieren, und dann können Entwickler das Paket einführen und verwenden.

Der Schlüssel liegt in der von Ihrem Projekt definierten Composer.json, die die Projektabhängigkeiten definieren kann. Es kann mehrere geben Pakete (es können mehrere sein) und die abhängigen Pakete können von anderen Paketen abhängen (das ist der Vorteil von Komponenten). Sie müssen sich nicht darum kümmern, dass Composer alles, was Sie brauchen, automatisch herunterlädt Composer.json.

Composer ist für Benutzer sehr transparent, aber das Konzept dahinter muss noch verstanden werden. Dank der rasanten Entwicklung von Github wird die PHP-Sprache immer beliebter modern, es sieht fortgeschrittener aus.

Um Composer zu verstehen, müssen Sie zunächst ein allgemeines Verständnis seiner Struktur haben:

Die Struktur von Composer

Composer-Befehlszeilentool:

Dieses Verständnis ist relativ einfach. Laden Sie den benötigten Code über die benutzerdefinierte Composer.json herunter. Wenn Sie einfach nur Composer verwenden, reicht es aus, einige spezifische Befehle zu beherrschen

Autoloading-Code-Loader:

Durch Composer können Entwickler es auf vielfältige Weise nutzen, und der Schlüssel liegt im Namespace-Konzept von PHP und der Entwicklung des PSR-4-Standards, auf dem Composer gerade einen Code entwickelt hat diese beiden Autoloader

Github:

Mit Github können PHP-Entwickler Open-Source-Code darauf hosten, und die Entwicklung von Composer stammt aus Github, der Essenz von Composer The Oben geht es darum, den Code auf Github lokal herunterzuladen.

Packagist:

Für Benutzer wird das Befehlszeilentool von Composer verwendet. Was ist also mit der Befehlszeile? Das Wissen, wie viele Pakete von Benutzern verwendet werden können, basiert hauptsächlich auf Packagist. Paketentwickler hosten bestimmte Codes auf Github und übermitteln Paketinformationen an Packagist, damit diese über Composer verwendet werden können.

Composer fragt Packagist basierend auf den lokal definierten Composer.json-Informationen ab und greift schließlich auch auf das Github-Warehouse zurück, wenn es um Composer.json geht Im Github-Repository sind drei Arten von Composer.json beteiligt, und ihre Bedeutungen sind unterschiedlich.

Composer.json:

Das ist der Kern von Composer Von Composer. Die drei Arten von Composer.json müssen bei der Verwendung immer beachtet werden, als ich das Composer-Befehlszeilentool lernte >Composer Init

Benutzer können Composer.json unter ihren eigenen Projekten erstellen, um die Abhängigkeitspakete Ihres Projekts zu definieren, oder sie können Composer.json interaktiv über Composer Init erstellen.

Composer Install

sollte der am häufigsten verwendete Befehl sein. Composer installiert das Paket basierend auf der lokalen Composer.json, legt das heruntergeladene Paket im Herstellerverzeichnis unter dem Projekt ab und legt es während der Installation auch ab

Wenn während der Installation festgestellt wird, dass die Version von Composer.lock mit der Codeversion im aktuellen Herstellerverzeichnis übereinstimmt, führt Composer nichts aus von .lock soll es Ihnen ermöglichen, beruhigt unter der aktuellen Version zu arbeiten, ohne die neueste Version des Pakets zu erhalten Neueste Version des Pakets? Was? Sie können die neueste Version des Pakets über diesen Befehl aktualisieren

composer config

Die globale Konfiguration wird in COMPOSER_HOME/ gespeichert. config.json und die nicht-globalen Konfigurationsinformationen werden im Verzeichnis dieses Projekts gespeichert.

composer config --list -gcomposer config -g notify-on-install falsecomposer global config bin-dir --absolute

composer create-project

Dieser Befehl wird nicht häufig verwendet, aber ich persönlich denke, dass es immer noch sehr wichtig ist, alle Abhängigkeitspakete von herunterzuladen Mit diesem Befehl können Sie den gesamten Code und die abhängigen Pakete in einem Verzeichnis ablegen, indem Sie einen Git-Clone-Befehl ausführen >composer global

Dies ist ein globaler Installationsbefehl, der es Ihnen ermöglicht, Composer-Befehle im COMPOSER_HOME-Verzeichnis auszuführen, wie z. B. install und update. Natürlich muss sich Ihr COMPOSER_HOME in der $PATH-Umgebung befinden. Wenn Sie Composer Global ausführen, benötigen Sie Fabpot/php-cs-fixer. Jetzt kann die Befehlszeile von PHP-CS-Fixer global ausgeführt werden. Wenn Sie es später aktualisieren möchten, müssen Sie nur Composer Global Update

Composer Dump ausführen -autoload

Wenn Sie die Datei „composer.json“ unter dem Projekt ändern, müssen Sie zum Aktualisieren nicht den Befehl „composer update“ ausführen. Manchmal können Sie diesen Befehl verwenden, um den Loader zu aktualisieren Um auf ein lokales benutzerdefiniertes Paket zu verweisen (nicht von packagist), wird dieser Befehl später durch Übung erläutert.

composer require

Wenn Sie die Datei „composer.json“ manuell oder interaktiv erstellen, können Sie sie verwenden Verwenden Sie diesen Befehl, um das Paket direkt zu installieren

composer require cerdic/css-tidy:1.5.2composer require "ywdblog/phpcomposer:dev-master"

–prefer-source und –prefer -dist-Parameter

–prefer-dist: Bei stabilen Paketen verwendet die Composer-Installation im Allgemeinen standardmäßig diesen Parameter, was die Installation beispielsweise auch ohne die Installation des entsprechenden Pakets direkt aus Packagist beschleunigen kann Laden Sie das Paket tatsächlich von Github herunter >composer require "ywdblog/phpcomposer:dev-master" --prefer-source

# Enthält .git-Informationen im Verzeichnis seller/ywdblog/phpcomposer

Anleitung Fügen Sie Composer einen Proxy hinzu

Der Download mit Composer in China ist extrem langsam, Sie können ihn mit zwei Methoden beschleunigen

composer config repo.packagist Composer „https://packagist.phpcomposer.com“

composer.json bearbeiten

"repositories": { "packagist": { "type": "composer", "url": "https://packagist.phpcomposer.com"

}

}

Autoloading Code Loader

Composer selbst integriert einen Autoloader, der PSR-4, PSR-0, Classmap und das automatische Laden von Dateien unterstützt.

Hier ist ein Beispiel, um zu veranschaulichen, wie Classmap und Dateien über Composer referenziert werden und der lokale Code dem PSR-4-Standard entspricht.

Composer.json bearbeiten

"autoload": { "classmap" : ["othsrc/","classsrc.php"], "files": ["othsrc/filesrc .php"], "psr-4": {"FooBar": "src"}

}

Composer Dump-Autoload

Durch die oben genannten Vorgänge gilt für PSR-4 dies als äquivalent zur Registrierung eines PSR-4-Autoloaders (aus dem FooBar-Namespace)

Wenn Sie es nicht tun Wenn Sie den Autoloader von Composer nicht verwenden möchten, können Sie die Datei „vendor/composer/autoload_*.php“ direkt einbinden und Ihren eigenen Loader konfigurieren.
Spezifische Beispiele werden auf Github gehostet, siehe

Repositories

Was Repositories betrifft, ist es nicht notwendig, sie zu verstehen, aber wenn Sie sie beherrschen, können Sie Composer For Repositories, seine chinesische Dokumentation und die englische Sprache besser verstehen. Das Dokument wird sehr gut erklärt, und einige Auszüge sind auch hier enthalten.

Grundlegende Konzepte

Paket:

Composer ist ein Abhängigkeitsverwaltungstool, das einige Ressourcenpakete lokal installiert und eine Beschreibung des Pakets (z. B. Paketname und entsprechende Version) enthält Wichtigere Metadatenbeschreibungen sind dist und source. dist verweist auf ein Archiv, bei dem es sich um ein Datenpaket einer bestimmten Version eines Ressourcenpakets handelt, das auf eine Entwicklungsquelle verweist, bei der es sich normalerweise um ein Quellcode-Repository (z. B. Git) handelt 🎜>

Repository:

Ein Repository ist die Quelle eines Pakets. Es ist eine Liste von Paketen/Versionen.

Composer durchsucht alle von Ihnen definierten Repositorys, um die Ressource zu finden Pakete, die für das Projekt erforderlich sind (dieser Satz ist sehr wichtig).

Packagist.org wurde standardmäßig bei Composer registriert (oder verstanden als Packagist.org ist der Standard-Warehouse-Typ der Composer-Ressourcenbibliothek)

Composer-Ressourcenbibliothekstyp

Die Composer-Ressourcenbibliothek umfasst vier Typen. Der Standardwert ist Composer-Typ, der von packagist.org verwendete Ressourcentyp.

Es wird eine einzelne Pakete.json-Datei verwendet das alle Ressourcenpaket-Metadaten enthält. Wenn Sie ein Paket auf pckagist.org veröffentlichen, erstellt das System standardmäßig eine packet.json, aber ich habe sie nicht. Finden Sie die Datei, die meinem Paket entspricht.

VCS-Ressourcenbibliothekstyp

Wenn Sie einen privaten Composer-Ressourcenbibliothekstyp erstellen möchten, können Sie diesen Typ verwenden. Dies ist beispielsweise der Fall, wenn Sie die Datei „composer.json“ Ihres eigenen Projekts verwenden wie folgt definiert, können Sie den entsprechenden Code auf Github verwenden.

{ "repositories": [ { „type“: „vcs“, „url“: „https://github.com/ywdblog/phpcomposer“ } ], „require“: { „ywdblog/phpcomposer“: „dev-master“ } }

Beim Ausführen des Composer-Updates lädt Comoser das Paket tatsächlich von Github statt von pckagist.org herunter.

Wenn Sie außerdem den Ressourcenbibliothekstyp „Paket“ oder den Ressourcenbibliothekstyp „PEAR“ verwenden müssen, Bitte beachten Sie die offizielle Dokumentation. Definieren Sie die Namens- und Versionsattribute in der Datei „composer.json“.

Composer.json wurde in diesem Artikel oft erwähnt. Wenn Sie beispielsweise ein Paket eines Drittanbieters verwenden möchten, müssen Sie Composer.json lokal definieren wird auch im Paketverzeichnis eines Drittanbieters gefunden, dann heißen beide „composer.json“. Was ist der Unterschied? Es ist sehr wichtig, das zu verstehen.

Wenn Sie eine „composer.json“ unter Ihrer eigenen definieren Dieses Paket wird als ROOT-Paket bezeichnet und definiert die für Ihr Projekt erforderlichen Bedingungen (z. B. kann Ihr Projekt von einem Paket eines Drittanbieters abhängen). nur vom ROOT-Paket verwendet werden, z. B. das config-Attribut nur im ROOT-Paket.

Ob ein Ressourcenpaket ein ROOT-Paket ist, hängt von seinem Kontext ab. Wenn Sie beispielsweise git clone ywdblog/ verwenden. phpcomposer, dann ist das lokale phpcomposer-Verzeichnis das ROOT-Paket. Wenn Sie sich im lokalen phpcomposer-Verzeichnis befinden, benötigt Composer ywdblog /phpcomposer, dann ist Ihr Projekt phpcomposer zu diesem Zeitpunkt das ROOT-Paket. schema.json, Sie können sich auf diese Website beziehen. Als ausgereiftes Framework ist Laravel's definiertes Composer.json sehr klassisch Geben Sie die spezifische Version des erforderlichen Pakets an. Composer unterstützt das Herunterladen von Paketen unter Tags oder Zweigen aus dem Github-Repository.

Für Tags auf Github erstellt Packagist eine Version des entsprechenden Pakets, die X.Y.Z, vX entspricht. Das heißt, obwohl es auf Github nur eine bestimmte Version des Pakets gibt, unterstützt Composer mehrere Referenzmethoden, wie zum Beispiel:

Composer erfordert Monolog/Monolog 1.0.0 -RC1

Komponist benötigt Monolog/Monolog v1.0.0-RC1

Komponist benötigt Monolog/Monolog 1.0.*

Komponist benötigt Monolog/Monolog ~1.10

Für Zweige auf Github: Packagist erstellt eine Version des entsprechenden Pakets. Wenn der Zweigname wie eine Version aussieht, wird eine Paketversion von {branch name}-dev erstellt. Wenn der Zweigname nicht wie eine Versionsnummer aussieht, wird eine erstellt Versionsnummer in Form von dev-{Zweigname}

composer require monolog/monolog master-dev
composer require monolog/monolog master .x-dev


Zusammenfassung:

Um Composer zu verstehen, ist Übung das Wichtigste. Schließlich können Sie PSR-4 und Namespaces verstehen und auch versuchen, Ihr Projekt auf pckagist.org zu veröffentlichen.

Das obige ist der detaillierte Inhalt vonDetaillierte Einführung in Composer. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!