Warum Aliase verwenden?

Die folgende Kolumne des Komponisten-Tutorials wird Ihnen die Gründe für die Verwendung von Filial-Aliassen vorstellen. Ich hoffe, dass es für Freunde in Not hilfreich sein wird!

Warum Aliase verwenden?

Wenn Sie ein Versionskontrollsystem-Repository verwenden, können Sie eine vergleichbare Version nur aus Zweigen erhalten, die wie Versionen aussehen, z. B. 2.0 oder 2.0.x. Für den Master-Zweig erhalten Sie nur eine Dev-Master-Version. Für den Bugfix-Zweig erhalten Sie die Dev-Bugfix-Version.

Wenn Ihr Hauptzweig zur Kennzeichnung des Entwicklungsprozesses von 1.0 verwendet wird, z. B. 1.0.1, 1.0.2, 1.0.3 usw., benötigen Pakete, die von Ihrer Bibliothek abhängen, möglicherweise 1.0.*.

Wenn jemand den neuesten Dev-Master verwenden möchte, wird er auf ein Problem stoßen: Einige Pakete erfordern möglicherweise 1.0.*, sodass diese beiden Konflikte verursachen, da Dev-Master nicht mit 1.0.* übereinstimmt.

Basierend auf dem oben Gesagten erscheinen Aliase.

Branch-Alias

Der Dev-Master-Zweig ist einer im Haupt-VCS-Repository. Es ist üblich, dass einige Leute die neueste Hauptentwicklungsversion möchten. Daher ermöglicht Ihnen Composer, den Dev-Master-Zweig mit einem Alias ​​auf die 1.0.x-Dev-Version zu versehen. Dies erfolgt durch Angabe des Branch-Alias-Felds unter „Extra“ in Composer.json:

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

Wenn es sich bei dem Alias ​​um eine nicht vergleichbare Version handelt (z. B. dev-develop), müssen Sie dem Branch-Namen dev- voranstellen. Sie können für vergleichbare Versionen auch Aliase hinzufügen (d. h. beginnend mit einer Zahl und endend mit .x-dev), jedoch nur als spezifischere Versionen. Beispielsweise kann 1.x-dev als 1.2.x-dev bezeichnet werden.

Der Alias ​​muss eine vergleichbare Entwicklungsversion sein und der Branch-Alias ​​muss in dem Zweig erscheinen, auf den er verweist. Für Dev-Master müssen Sie es im Master-Zweig festschreiben.

Viele Leute brauchen jetzt also 1.0.* und er wird gerne dev-master installieren.

Um einen Branch-Alias ​​zu verwenden, müssen Sie Eigentümer des Repositorys für das Alias-Paket sein. Wenn Sie einem Drittanbieterpaket einen Alias ​​hinzufügen möchten, ohne einen Fork davon zu verwalten, verwenden Sie Inline-Aliase, wie unten beschrieben.

Erfordert Inline-Aliase

Zweig-Aliase sind für Hauptentwicklungslinien nützlich. Um sie jedoch verwenden zu können, müssen Sie das Quell-Repository kontrollieren und Änderungen müssen der Versionskontrolle übergeben werden.

Es ist nicht sehr interessant, wenn Sie versuchen möchten, einen Fehler für eine Bibliothek zu beheben, die von Ihrem lokalen Projekt abhängig ist.

So können Sie Pakete in den Feldern require und require-dev mit Aliasen versehen. Angenommen, Sie finden einen Fehler im Paket monolog/monolog. Sie klonen Monolog auf GitHub und beheben das Problem in einem Zweig namens Bugfix. Jetzt möchten Sie diese Version von Monolog in Ihrem lokalen Projekt installieren.

Sie verwenden Symfony/Monolog-Bundle, das Monolog/Monolog Version 1.* erfordert. Daher müssen Sie dev-bugfix verwenden, um diese Einschränkung zu erfüllen.

Fügen Sie dies zum Root-Composer.json Ihres Projekts hinzu:

{
    "repositories": [
        {
            "type": "vcs",
            "url": "https://github.com/you/monolog"
        }
    ],
    "require": {
        "symfony/monolog-bundle": "2.0",
        "monolog/monolog": "dev-bugfix as 1.0.x-dev"
    }
}

Dadurch wird die Version des Dev-Bugfix von Monolog/Monolog von Ihrem Github abgerufen und mit einem Alias ​​auf 1.0.x -dev versehen.

Hinweis: Inline-Aliasing ist eine Nur-Root-Funktion. Wenn ein Paket mit einem Inline-Alias ​​erforderlich ist, verwenden Sie den Alias ​​(rechte Seite von as ) als Versionseinschränkung. Der linke Teil von as wird verworfen. Wenn A also B benötigt und B die Monolog-/Monolog-Version benötigt, ist dev-bugfix 1.0.x-dev , dann erfordert die Installation von A, dass B auch 1.0.x-dev benötigt, das als Zweigalias oder als tatsächliche Version 1.0 vorhanden sein kann Zweig. Wenn nicht, müssen Sie den Alias ​​erneut inline in A's „composer.json“ einfügen.

Hinweis: Die Verwendung von Inline-Aliasnamen sollte vermieden werden, insbesondere für veröffentlichte Pakete/Bibliotheken. Wenn Sie einen Fehler finden, versuchen Sie, Ihren Fix mit den Originalautoren zusammenzuführen. Dies wird dazu beitragen, Probleme für Benutzer Ihres Pakets zu vermeiden.

Weitere technische Artikel zu Composer finden Sie in der Tutorial-Spalte Composer-Befehl!

Das obige ist der detaillierte Inhalt vonWarum Aliase verwenden?. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!