Usage avancé de Composer – Using Zend Framework 3

Translation into this language is not yet finished. You can help this project by translating the chapters and contributing your changes.

2.12. Usage avancé de Composer

Précédemment, nous avons utilisé Composer pour installer la bibliothèque Zend Framework 3. Décrivons maintenant brièvement quelques exemples d'utilisation avancés de Composer.

Comme nous le savons déjà, la seule clé requise dans le fichier composer.json est require. Cette clé indique quels sont les paquetages requis par votre application :

{
    "require": {
        "php": "^5.6 || ^7.0",
        "zendframework/zend-component-installer": "^1.0 || ^0.3 || ^1.0.0-dev@dev",
        "zendframework/zend-mvc": "^3.0.1",
        "zfcampus/zf-development-mode": "^3.0",
        "zendframework/zend-mvc-form": "^1.0",
        "zendframework/zend-mvc-plugins": "^1.0.1",
        "zendframework/zend-session": "^2.7.1"
    }
}

2.12.1. Noms des Packages et Versions

Un nom de package se compose de deux parties : le nom du fournisseur (vendor) et le nom du projet. Par exemple, le nom du paquet "zendframework/zend-mvc" se compose du nom du fournisseur "zendframework" et du nom du projet "zend-mvc". Vous pouvez rechercher d'autres packages du fournisseur "zendframework" sur le site Packagist.org (voir la figure 2.8 pour un exemple).

Figure 2.8. Vous pouvez rechercher des paquets sur Packagist.org

Un package a également un numéro de version associé. Un numéro de version se compose d'un numéro majeur, d'un numéro mineur, d'un numéro de build facultatif et d'un suffixe de stabilité facultatif (par exemple b1, rc1). Dans la clé require, nous spécifions quelles versions du paquet nous acceptons. Par exemple, "^5.6" signifie que nous pouvons installer des versions supérieures à "5.6", mais inférieures à "6.0" (ie que nous ne pouvons installer que les paquets qui ne cassent pas la compatibilité descendante). Dans le tableau 2.2, les manières possibles de spécifier les versions acceptables sont présentées:

Table 2.2. Définitions des versions de Package

Exemple	Description
3.0.1	Version exacte. Dans cet exemple, seule la version 3.0.1 peut être installée.
>=3.0.1	Une version supérieure ou égale peut être installée (3.0.1, 3.2.1, etc.)
>3.0.1	Une version ultérieure peut être installée (3.0.2 etc.)
<=3.0.1	Une version inférieure ou égale peut être installée (1.0, 1.5, 2.0.0 etc.)
<3.0.1	Une version strictement inférieure peut être installée (1.0, 1.1, 1.9, etc.)
!=3.0.1	Toutes les versions sauf cette version peuvent être installées.
>=3.0,<3.1.0	Toute version appartenant à cette gamme de versions peut être installée.
3.*	Toute version ayant un numéro majeur égal à 3 peut être installée (peu importe le numéro mineur).
~3.0	Toute version à partir de 3.0, mais inférieure à la version majeure suivante (équivalent de > 3.0, <4.0).
^3.0	Toute version à partir de la version 3.0, mais inférieure à la version majeure suivante (équivalente à >= 3.0, <4.0). Semblable à ~3.0, mais il se rapproche de la version sémantique, et permettra toujours des mises à jour sans rupture.

2.12.2. Installation et mise à jour des paquets

Nous avons vu comment utiliser la commande php composer.phar install pour installer nos dépendances. Dès que vous appelez cette commande, Composer trouve, télécharge et installe les dépendances dans votre sous-dossier vendor.

L'instalation des dépendances avec Composer est elle sure ?

Eh bien, certaines personnes peuvent avoir peur des gestionaires des dépendances du style Composer car elles pensent que quelqu'un peut mettre à jour les dépendances du système par erreur ou intentionnellement, provoquant la rupture de l'application. Notez que Composer n'installe jamais ces systèmes à la place de vos fichiers, mais les installe dans votre répertoire APP_DIR/vendor/.

Après l'installation, Composer crée également le fichier APP_DIR/composer.lock. Ce fichier contient maintenant les versions réelles des packages installés. Si vous réexécutez la commande d'installation, Composer intérogera le fichier composer.lock, vérifiera les dépendances déjà installées et, comme tous les paquets sont déjà installés et à jour, il se fermera simplement sans rien faire.

Supposons maintenant que, à un moment donné, de nouvelles mises à jour de sécurité pour vos paquets de dépendances soient publiées. Vous voudrez mettre à jour vos paquets pour garder votre site web sécurisé. Vous pouvez le faire en tapant ce qui suit :

php composer.phar update

Si vous souhaitez mettre à jour une seule dépendance, tapez son nom comme suit :

php composer.phar update zendframework/zend-mvc

Après la commande update, votre fichier composer.lock sera également mis à jour.

Que faire si je souhaite revenir à une version antérieure du package ?

Si la procédure de mise à jour a provoqué des problèmes indésirables sur votre système, vous pouvez revenir en arrière en rétablissant les modifications apportées à votre fichier composer.lock et en réexécutant la commande d'installation. La restauration des modifications de composer.lock est facile si vous utilisez un système de contrôle de version, comme GIT ou SVN. Si vous n'utilisez pas de système de contrôle de version, faites une copie de sauvegarde de composer.lock avant la mise à jour.

2.12.3. Ajouter une nouvelle dépendance

Si vous souhaitez ajouter une nouvelle dépendance à l'application, vous pouvez éditer composer.json manuellement ou taper une commande require. Par exemple, pour installer le module Doctrine ORM sur votre site (pour ajouter le package "doctrine/doctrine-module" aux dépendances de l'application), tapez ce qui suit :

php composer.phar require doctrine/doctrine-module 2.*

La commande ci-dessus édite le fichier composer.json et télécharge et installe le paquet. Nous utiliserons cette commande plus tard dans le chapitre Managing Database with Doctrine, lorsque nous nous familiariserons avec la gestion de base de données.

2.12.4. Paquets Virtuels

Composer peut être utilisé pour exiger certaines fonctionnalités nécessaires à votre système. Vous avez déjà vu que nous avions besoin de "php:^5.6". Le paquet PHP est un paquet virtuel représentant PHP lui-même. Vous pouvez également exiger d'autres choses, comme les extensions PHP (voir le tableau 2.3 ci-dessous).

Table 2.3. Paquets Virtuels Composer

Exemple	Description
"php":"^5.6"	Requiert une version PHP supérieure ou égale à 5.6, mais inférieure à 6.0.
ext-dom, ext-pdo-mysql	Nécessite les extensions PHP DOM et PDO MySQL
lib-openssl	Nécessite la bibliothèque OpenSSL

Vous pouvez utiliser la commande php composer.phar show --platform pour afficher la liste des packages virtuels disponibles pour votre machine.

2.12.5. Composer et les gestionnaires de version

Si vous utilisez un système de contrôle de version (comme Git), vous serez curieux de savoir ce qui devrait être stocké dans Git : seulement le code de votre application ou votre code plus toutes les dépendances installées par Composer dans APP_DIR/vendor ?

En général, il n'est pas recommandé de stocker vos dépendances Composer dans le gestionnaire de version car cela peut rendre votre dossier très gros et trop lent à extraire et à brancher. Au lieu de cela, vous devez stocker votre fichier composer.lock sous le contrôle de version. Le fichier composer.lock garantit que tout le monde va installer les mêmes versions de dépendances que vous. Ce qui est utile dans les équipes de développement ayant plus d'un développeur car tous les développeurs doivent avoir le même code pour éviter les problèmes non désirés avec une mauvaise configuration de l'environnement.

Et si une dépendance était déclarée obsolète et retirée de Packagist.org ?

Eh bien, la possibilité de retrait du paquet est minimale. Tous les paquets sont libres et open-source et la communauté d'utilisateurs peut toujours restaurer la dépendance même si elle est retirée de packagist. En passant, le même concept d'installation de dépendances est utilisé sous Linux (souvenez-vous du gestionnaire APT ou RPM?), est ce que quelqu'un a déjà perdu un paquet Linux ?

Mais il peut arriver que vous deviez stocker certaines bibliothèques dépendantes sous le contrôle de version :

Si vous devez apporter des modifications personnalisées au code tiers. Par exemple, supposons que vous deviez corriger un bug dans une bibliothèque et que vous ne pouvez pas attendre que le fournisseur de la bibliothèque le corrige pour vous (ou si le fournisseur de la bibliothèque ne peut pas corriger le bug). Dans ce cas, vous devez placer le code de la bibliothèque sous contrôle de version pour vous assurer que vos modifications personnalisées ne seront pas perdues.
Si vous avez écrit un module ou une bibliothèque réutilisable et souhaitez le stocker dans le répertoire du fournisseur sans le publier sur Packagist.org. Étant donné que vous n'avez pas la possibilité d'installer ce code à partir de Packagist, vous devez le stocker sous le contrôle de version.
Si vous voulez une garantie à 100% qu'un paquet tiers ne sera pas perdu. Bien que le risque soit minime, pour certaines applications, il est essentiel d'être autonome et de ne pas dépendre de la disponibilité des paquets sur Packagist.org.