Composer est un outil de gestion des dépendances de packages PHP très populaire. Il a remplacé le gestionnaire de packages PEAR. Il est nécessaire que les développeurs PHP maîtrisent Composer.
Pour les utilisateurs, Composer est très simple. package dans le répertoire du fournisseur avec une simple commande, puis les développeurs peuvent introduire le package et l'utiliser
La clé réside dans le composer.json défini par votre projet, qui peut définir les dépendances du projet. Il peut y en avoir plusieurs. packages (il peut y en avoir plusieurs), et les packages dépendants peuvent dépendre d'autres packages (c'est l'avantage des composants). Composer téléchargera automatiquement tout ce dont vous avez besoin. composer.json.
Composer est très transparent pour les utilisateurs, mais le concept qui le sous-tend doit encore être compris. Sa naissance n'est pas accidentelle. Grâce au développement rapide de Github, le langage PHP devient de plus en plus répandu. moderne. , il a l'air plus avancé.
Afin de comprendre Composer, ayez d'abord une compréhension générale de sa structure :
La structure de Composer
L'outil de ligne de commande Composer :
Cette compréhension est relativement simple. Téléchargez le code dont vous avez besoin via Composer.json défini par l'utilisateur. Si vous utilisez simplement Composer, il suffit de maîtriser certaines commandes spécifiques
Chargeur de code à chargement automatique :
Grâce à Composer, les développeurs peuvent l'utiliser de différentes manières, et la clé réside dans le concept d'espace de noms de PHP et le développement du standard PSR-4 que Composer vient de développer un code basé sur. ces deux Autoloader
Github :
Avec Github, les développeurs PHP peuvent y héberger du code open source, et le développement de Composer est originaire de Github, l'essence de Composer The ci-dessus consiste à télécharger le code sur Github en local.
Packagist :
Pour les utilisateurs, l'outil de ligne de commande de Composer est utilisé, alors qu'en est-il de la ligne de commande Savoir combien de packages peuvent être utilisés par les utilisateurs repose principalement sur Packagist. Packagist est le principal référentiel d'informations sur les packages de Composer. Les développeurs de packages hébergent des codes spécifiques sur Github et soumettent les informations sur les packages à Packagist, afin que les utilisateurs puissent les utiliser via Composer. >Composer interroge Packagist sur la base des informations composer.json définies localement, analyse sur la base des informations Composer.json/Package.json et correspond enfin à l'entrepôt github. Composer s'en sert également lors du téléchargement du code concernant Composer.json. Dépôt Github, il existe trois types de composer.json impliqués, et leurs significations sont différentes
C'est le cœur de Composer, ce sont les règles. de Composer. Les trois types de Composer.json sont également mentionnés ci-dessus. Vous devez faire attention à la distinction lorsque vous les utilisez. J'ai toujours raté la première fois que j'ai appris
composer init
Les utilisateurs peuvent créer composer.json sous leurs propres projets pour définir les packages de dépendances de votre projet, ou ils peuvent créer composer.json de manière interactive via composer init.
composer install
devrait être la commande la plus couramment utilisée. Composer installera le package en fonction du composer.json local, placera le package téléchargé dans le répertoire du fournisseur sous le projet et mettra également les informations sur la version du package lors de l'installation. .lock pour verrouiller la version.
En fait, lors de l'installation, s'il s'avère que la version de composer.lock est cohérente avec la version du code dans le répertoire actuel du fournisseur, Composer ne fera rien. .lock est pour vous permettre de travailler l'esprit tranquille sous la version actuelle sans obtenir la dernière version du package
mise à jour du compositeur
Alors comment mettre à jour composer.lock pour obtenir la dernière. version du package Quoi ? Vous pouvez mettre à jour la dernière version du package via cette commande
composer config
Il est recommandé de comprendre cette commande. La configuration globale est enregistrée dans COMPOSER_HOME/config. json, et les informations de configuration non globales sont stockées dans le répertoire de ce projet.
composer config --list -gcomposer config -g notify-on-install falsecomposer global config bin-dir --absolute
composer create-project
Cette commande n'est pas couramment utilisée, mais je pense personnellement qu'elle est toujours très importante. Utiliser la commande d'installation ordinaire consiste à télécharger tous les packages de dépendances du projet. le répertoire du fournisseur du projet. Avec cette commande, tout le code et placer les packages dépendants dans un répertoire équivaut à exécuter une commande git clone. Généralement, les développeurs de packages peuvent utiliser cette commande pour corriger les bugs
composer. mondiale
Il s'agit d'une commande d'installation globale, qui vous permet d'exécuter des commandes Composer dans le répertoire COMPOSER_HOME, telles que l'installation et la mise à jour. Bien entendu, votre COMPOSER_HOME doit être dans l'environnement $PATH.
Par exemple, exécuter composer global require fabpot/php-cs-fixer, la ligne de commande php-cs-fixer peut désormais être exécutée globalement. Si vous souhaitez la mettre à jour plus tard, il vous suffit d'exécuter composer global update
composer dump. -autoload
Lorsque vous modifiez le fichier composer.json sous le projet, vous n'avez pas besoin d'exécuter la commande composer update pour le mettre à jour. Parfois, vous pouvez utiliser cette commande pour mettre à jour le chargeur, par exemple, si vous. souhaitez référencer un package personnalisé local (pas de packagist), cette commande sera expliquée plus tard dans la pratique
composer require
Si vous créez le fichier composer.json manuellement ou de manière interactive, vous pouvez. utilisez cette commande directement pour installer le package
composer require cerdic/css-tidy:1.5.2composer require "ywdblog/phpcomposer:dev-master"
–prefer-source et – Paramètres préfère-dist
–prefer-dist : Pour les packages stables, l'installation de Composer utilise généralement ce paramètre par défaut, ce qui peut également accélérer l'installation. Par exemple, il est possible d'installer le package correspondant directement depuis packagist. sans réellement télécharger le package depuis Github.
–prefer -source : si ce paramètre est utilisé, il sera installé directement depuis Github. Après l'installation du package, le répertoire du fournisseur contient également des informations .git
<.>composer require "ywdblog/phpcomposer:dev-master" --prefer-source# Contient des informations .git dans le répertoire supplier/ywdblog/phpcomposer
>
}
}
Grâce aux opérations ci-dessus, pour PSR-4, cela équivaut à enregistrer un autoloader PSR-4 (à partir de l'espace de noms FooBar)
Des exemples spécifiques sont hébergés sur github, veuillez vous référer aux
Type de bibliothèque de ressources ComposerLa bibliothèque de ressources Composer comprend quatre types, la valeur par défaut est le type composer, qui est le type de ressource utilisé par packagist.org.Il utilise un seul packages.json fichier qui contient toutes les métadonnées du package de ressources. Lorsque vous publiez un package sur pckagist.org, le système créera un packages.json par défaut, mais je ne l'ai pas. Trouvez le fichier correspondant à mon package.
Type de bibliothèque de ressources VCS
Si vous souhaitez créer un type de bibliothèque de ressources privée Composer, vous pouvez utiliser ce type. Par exemple, si vous êtes le composer.json de votre propre projet. est défini comme suit, vous pouvez utiliser le code correspondant sur Github.
{ "repositories": [ { "type": "vcs", "url": "https://github.com/ywdblog/phpcomposer" } ], "require": { "ywdblog/phpcomposer": "dev-master" } >
Lors de l'exécution de la mise à jour du compositeur, Comoser télécharge en fait le package depuis Github au lieu de depuis pckagist.org.
De plus, si vous devez utiliser le type de bibliothèque de ressources Package ou le type de bibliothèque de ressources PEAR , veuillez vous référer à la documentation officielle. Généralement, définissez les attributs de nom et de version dans composer.json
Composer.json
.Composer.json a été mentionné à plusieurs reprises dans cet article. Par exemple, si vous souhaitez utiliser un package tiers, vous devez définir composer.json localement après que Composer ait installé le package tiers, composer.json. se trouvera également dans le répertoire du package tiers, alors les deux s'appellent composer.json, quelle est la différence Il est très important de comprendre cela.
Si vous définissez un composer.json sous le vôtre ? projet, ce package est appelé package ROOT. Ce composer.json définit les conditions requises par votre projet (par exemple, votre projet peut dépendre d'un package tiers
Certains attributs dans composer.json peuvent). ne doit être utilisé que par le package ROOT, comme l'attribut config uniquement dans le package ROOT.
Le fait qu'un package de ressources soit un package ROOT dépend de son contexte. Par exemple, si vous git clone ywdblog/. phpcomposer, alors le répertoire phpcomposer local est le package ROOT Si vous êtes dans le répertoire phpcomposer local, composer nécessite ywdblog /phpcomposer, alors votre projet phpcomposer est le package ROOT en ce moment
Pour en savoir plus sur composer-. schema.json, vous pouvez vous référer à ce site Web. En tant que framework mature, le composer.json défini par Laravel est très classique
À propos de la version du package
Lorsque les utilisateurs configurent composer.json localement, ils peuvent spécifiez la version spécifique du package requise. Composer prend en charge le téléchargement de packages sous des balises ou des branches à partir du référentiel Github.
Pour les balises sur Github, Packagist créera une version du package correspondant, conforme à X.Y.Z, vX. Types de packages Y.Z, X.Y.Z. Autrement dit, bien qu'il n'existe qu'une seule version spécifique du package sur Github, Composer prend en charge plusieurs méthodes de référence, telles que :
composer require monolog/monolog 1.0.0. -RC1
composer require monolog/monolog v1.0.0-RC1
composer require monolog/monolog 1.0.*
composer require monolog/monolog ~1.10
Pour les branches sur Github, Packagist créera une version du package correspondant. Si le nom de la branche ressemble à une version, une version du package de {branch name}-dev sera créée, si le nom de la branche ne ressemble pas à un numéro de version, il créera un numéro. numéro de version sous la forme dev-{nom de la branche>
composer require monolog/monolog master-dev
composer require monolog/monolog master .x-dev
Résumé :
Pour comprendre Composer, le plus important est la pratique. Enfin, vous pouvez comprendre PSR-4 et les espaces de noms, et vous pouvez également essayer de publier votre projet sur pckagist.org.
Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!