Wenn Sie Composer noch nicht kennen, gehen Sie bitte zu Tutorial zur Composer-NutzungSpalte und beginnen Sie mit dem Lesen.
Ich habe viele Leute gesehen, die mit Einschränkungen bei Abhängigkeiten zwischen den von ihnen verwendeten Composer-Paketen zu kämpfen haben. Wir hoffen, dass dieser Artikel die Ursachen einiger Probleme aufzeigt und Möglichkeiten aufzeigt, diese zu vermeiden. Ich beginne mit dem Worst-Case-Szenario und verbessere die Einschränkungen Schritt für Schritt.
Allmächtiger Sternchen: *
Composer hat einen Abhängigkeitsparser, sodass er automatisch herausfindet, was ich will, oder? falsch.
Das Deklarieren einer Versionseinschränkung mit * ist wahrscheinlich eine der schlechtesten Vorgehensweisen. Weil Sie absolut keine Kontrolle darüber haben, was Sie bekommen. Es kann sich um eine beliebige Version handeln, die mit minimum-stability und anderen Einschränkungen übereinstimmt.
Im Grunde spielen Sie mit Composer eine Partie russisches Roulette, und am Ende wird es Ihnen schaden. Dann könnten Sie dem Tool die Schuld geben, dass es Sie enttäuscht hat.
Wenn Sie weiterhin nachlässig sind, verlassen Sie sich bitte zumindest auf die neueste Entwicklungsversion, die normalerweise mit dev-master gekennzeichnet ist.
fest verdrahteter Zweigname
Sie verwenden also jetzt dev-master. Das Problem besteht darin, dass sich der Code, auf den dev-master zeigt, ändern kann. Zumindest erhalten Sie immer ein instabiles Paket (instabil gemäß dem von Composer dargestellten Stabilitätsflag). Das größere Problem besteht jedoch darin, dass sich die Bedeutung von dev-master jederzeit ändern kann.
Zum Beispiel stellt es jetzt die neueste Entwicklungsversion 1.0 dar. Wenn Entwickler sagen, dass sie mit der Entwicklung von Version 1.1 beginnen werden, dev-master verweist der Zweigname nicht mehr auf den 1.0-Zweig, sondern auf den neuesten 1.1-Entwicklungszweig.
Wenn Sie die Entwicklung dieser Bibliothek nicht genau verfolgen, wird Ihnen das Problem erst auffallen, wenn Sie den Befehl composer update ausführen, was Ihnen den Tag ruiniert. Daher ist die direkte Nennung des Filialnamens keine nachhaltige Lösung. Glücklicherweise kann composer beim Aliasing helfen.
Zweigalias
Zweigalias ist ein Attribut, das Paketbetreuer in ihr composer.json einfügen können, wodurch diese Zweignamen Versionen zugeordnet werden können.
Zweignamen wie 1.0, 2.1 usw. sind nicht erforderlich, Composer diese wurden berücksichtigt.
Aber ein Zweigname wie master führt zu einer Version mit dem Namen dev-master , für die Sie einen Alias angeben müssen. In der Composer -Dokumentation gibt es einen guten Artikel über Aliase, in dem erklärt wird, wie Zweigaliase definiert werden: Die Version
{
"extra": {
"branch-alias": {
"dev-master": "1.0.x-dev"
}
}
}dev-master wird einem Alias von 1.0.x-dev ,
zugeordnet Das bedeutet im Grunde, dass Sie Pakete mit einer 1.0.*@dev-Einschränkung anfordern können. Dies hat den Vorteil, dass die Bedeutung von 1.0 definiert wird und sich nicht ändert. Außerdem wird dadurch der Wechsel zu stabilen Versionen einfacher.
Warnungen zu Branch-Aliassen erfordern, dass Paketbetreuer diese einfügen. Wenn Sie eine Bibliothek verwenden, die keinen Branch-Alias hat, senden Sie ihr einen Pull-Request und fügen Sie den Abschnitt extra oben zu ihrem composer.json hinzu.
Stabile Version
1.0.*@dev Diese Einschränkung ist bereits sehr gut. Das Problem ist jedoch, dass es bisher noch keine stabile Version gibt. An Ihrem Code ist nichts auszusetzen, außer der Tatsache, dass Sie immer noch eine instabile Version ausführen.
Aber wenn das Projekt einer anderen Person von Ihrem Paket abhängt, müssen Ihre Benutzer explizit das @dev -Flag verwenden, um Composer die Installation instabiler Versionen zu ermöglichen, oder einfach das Projekt herunterstufen minimum-stability, was bedeutet, dass sie instabile Versionen von erhalten alle abhängigen Pakete.
Der beste Weg, Instabilität in der Entwicklungsversion zu vermeiden, besteht darin, das Release-Tag zu setzen (bezieht sich auf die Veröffentlichung einer stabilen Version). Wenn Sie eine Bibliothek verwenden, die nicht mit release gekennzeichnet ist, benachrichtigen Sie deren Betreuer, bis sie mit einem Tag versehen ist. Mach es jetzt!
Als Teil der Komponisten-Community müssen wir Verantwortung übernehmen. Wir müssen stabile Versionen veröffentlichen und sollten ein CHANGELOG (Änderungsprotokoll) führen. Es wird nicht einfach sein, aber es wird einen großen Unterschied für das gesamte Ökosystem machen. Denken Sie daran, die Dinge wahrheitsgemäß und semantisch zu kennzeichnen.
Wenn Sie eine stabile Version veröffentlichen, können Sie das Tag @dev entfernen und Ihre Einschränkungen in 1.0.* ändern.
Die nächste Hauptversion
Wenn jeder Release-Knoten des Pakets, von dem Sie abhängig sind, die Regeln der semantischen Versionierung einhält und streng abwärtskompatibel ist, können Sie dies schrittweise tun die Einschränkungen erhöhen.
Die 1.0.* -Version weist jetzt einige potenzielle Kompatibilitätsprobleme auf und die 1.1-Version wird bald veröffentlicht. Wenn Ihre Einschränkung 1.0 ist, aber jemand anderes die neuen Funktionen der 1.1-Version benötigt (erinnern Sie sich an die Abwärtskompatibilität?), kann er die 1.1-Version nicht installieren. Sie müssen also Ihre Einschränkungen umschreiben, etwa: 1.* .
Großartig, solange Sie sich nicht auf die neuen Funktionen der 1.1-Version verlassen, müssen Sie die Einschränkung nicht ändern und sie entspricht immer noch der 1.0 -Version ohne die neuen Funktionen.
Als nächstes ändern Sie die Einschränkung in >=1.1,<2.0 , aber diese Schreibweise ist problematischer. Mit dem Tilde-Operator können Sie den obigen Ausdruck prägnant darstellen: ~1.1 . Dies bedeutet jede 1.*-Version über 1.1. Jetzt wissen Sie, dass semantische Versionen empfohlen werden, den Tilde-Operator zu verwenden und die Paketkompatibilität zu maximieren.
TLDR
Verwenden Sie branch-alias. Das
-Tag veröffentlicht, um die Veröffentlichung zuverlässiger und semantischer zu machen.
verwendet den ~ -Operator.
Das obige ist der detaillierte Inhalt vonEinschränkungen der Composer-Version, die Sie kennen müssen. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!
