Contraintes de version du compositeur que vous devez connaître

Si vous ne connaissez pas encore le compositeur, veuillez consulter le tutoriel d'utilisation du compositeurColonne et commencez à lire.

J'ai vu beaucoup de gens aux prises avec des contraintes de dépendances entre les packages de composition qu'ils utilisent. Espérons que cet article soulignera les causes de certains problèmes et proposera des moyens de les éviter. Je vais commencer par le pire des cas et améliorer les contraintes étape par étape.

Astérisque tout-puissant : *

Composer a un analyseur de dépendances, donc il détermine automatiquement ce que je veux, n'est-ce pas ? faux.

Déclarer une contrainte de version avec * est probablement l'une des pires pratiques. Parce que vous n’avez absolument aucun contrôle sur ce que vous obtenez. Il peut s'agir de n'importe quelle version correspondant à minimum-stability et à d'autres contraintes.

En gros, vous jouez à une partie de roulette russe avec Composer, et cela finira par vous faire du mal. Vous pourriez alors reprocher à l’outil de vous avoir déçu.

Si vous continuez à être négligent, veuillez au moins vous fier à la dernière version de développement, généralement marquée dev-master.

nom de la branche câblée

vous utilisez donc dev-master maintenant. Le problème est que le code pointé par dev-master peut changer. Au moins, ce que vous obtenez est toujours un package instable (instable selon l'indicateur de stabilité représenté par composer). Le plus gros problème, cependant, est que la signification de dev-master peut changer à tout moment.

Par exemple, il représente désormais la dernière version de développement 1.0. Lorsque les développeurs disent qu'ils vont commencer à développer la version 1.1, dev-master le nom de la branche ne pointe plus vers la branche 1.0, il commence à pointer vers la dernière branche de développement 1.1.

À moins que vous ne suiviez de près le développement de cette bibliothèque, le problème ne vous apparaîtra que lorsque vous exécuterez la commande composer update , gâchant ainsi votre journée. Par conséquent, faire référence directement au nom de la succursale n’est pas une solution durable. Heureusement, composer peut vous aider en matière d'alias.

Alias ​​de branche

L'alias de branche est un attribut que les responsables du paquet peuvent mettre dans leur composer.json , permettant à ces noms de branche d'être mappés aux versions.

Les noms de branches comme 1.0, 2.1 etc. ne sont pas obligatoires, Composer ceux-ci ont été pris en charge.

Mais un nom de branche comme master donnera lieu à une version nommée dev-master , que vous devez alias. Il y a un bon article sur les alias dans la documentation Composer , qui explique comment définir les alias de branche : la version

{
    "extra": {
        "branch-alias": {
            "dev-master": "1.0.x-dev"
        }
    }
}

dev-master sera mappée sur un alias de 1.0.x-dev ,

Cela signifie essentiellement que vous pouvez exiger des packages avec une contrainte 1.0.*@dev. L’avantage est que la signification de 1,0 sera définie et ne changera pas. Cela facilitera également le passage aux versions stables.

Les avertissements sur les alias de branche nécessitent que les responsables du paquet les insèrent. Si vous utilisez une bibliothèque qui n'a pas d'alias de branche, envoyez-leur une pull request en ajoutant la section extra ci-dessus à leur composer.json .

Version stable

1.0.*@dev Cette contrainte est déjà très bonne. Mais le problème est que jusqu’à présent, il n’existe toujours pas de version stable. Il n'y a rien de mal avec votre code autre que le fait que vous utilisez toujours une version instable.

Mais si le projet de quelqu'un d'autre dépend de votre package, alors vos utilisateurs doivent utiliser explicitement l'indicateur @dev pour permettre à Composer d'installer des versions instables, ou simplement rétrograder le projet minimum-stability, ce qui signifie qu'ils obtiendront des versions instables de tous les packages dépendants.

La meilleure façon d'éviter l'instabilité dans la version de développement est de mettre la balise release (faisant référence à la sortie d'une version stable). Si vous utilisez une bibliothèque qui n'est pas balisée release , alertez son responsable jusqu'à ce qu'elle soit balisée. Faites-le maintenant !

En tant que membres de la communauté Composer, nous devons être responsables. Nous devons publier des versions stables et maintenir un CHANGELOG (journal des modifications). Ce ne sera pas facile, mais cela fera une énorme différence pour l’ensemble de l’écosystème. N'oubliez pas d'étiqueter les choses de manière véridique et sémantique.

Lorsque vous publiez une version stable, vous pouvez supprimer la balise @dev et changer vos contraintes en 1.0.*.

La prochaine version majeure

Si chaque nœud de version du package dont vous dépendez adhère aux règles de gestion des versions sémantiques et est strictement rétrocompatible, alors vous pouvez progressivement augmenter les contraintes.

La version 1.0.* présente désormais des problèmes de compatibilité potentiels et la version 1.1 sera bientôt publiée. Si votre contrainte est 1.0 , mais que quelqu'un d'autre a besoin des nouvelles fonctionnalités de la version 1.1 (vous vous souvenez de la rétrocompatibilité ?), il ne peut pas installer la version 1.1. Vous devez donc réécrire vos contraintes, comme : 1.* .

Génial, à moins que vous ne commenciez à vous appuyer sur les nouvelles fonctionnalités de la version 1.1, vous n'avez pas besoin de modifier la contrainte et elle correspondra toujours à la version 1.0 sans les nouvelles fonctionnalités.

Ensuite, vous modifiez la contrainte en >=1.1,<2.0 , mais cette façon d'écrire est plus gênante. L'utilisation de l'opérateur tilde vous permet de représenter l'expression ci-dessus de manière concise : ~1.1 . Cela signifie toute version 1.* supérieure à 1.1. Vous savez maintenant que les versions sémantiques sont encouragées à utiliser l'opérateur tilde et à maximiser la compatibilité des packages.

TLDR

Utilisez branch-alias. La balise

publie pour rendre la publication plus fiable et sémantique

utilise l'opérateur ~ .

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!