Kann ich den PSR 4 Autoload Namespace mit einem Fallback ändern?

Question

Ich habe ein öffentliches Paket auf Packagist/Komponist.

Ursprünglich wurde es mit PSR-4 \ GitHubUser \ Package \ Class für die Datei src/Class.php automatisch geladen.

Ich möchte dies zu \ Package \ Class für die gleiche Datei verkürzen. Dies ist leicht durch Ändern der composer.json möglich. Aber gibt es einen Weg, wie ich das mit einem Fallback für Leute machen kann, die den bestehenden längeren Anruf nutzen? (Automatisches Laden beides?)

Was Ich mag würde:

"autoload": { 
    "psr-4": { 
     "PackageName\\": "src", 
     "User\\OldPackageName\\": "src" 
    } 
} 

Aber es registriert nicht den 2. Anruf für den gleichen Ordner.

Answer 1

Sie müssen einen Weg finden, dass die eine Datei, die geladen wird, die richtige einzelne Klasse oder beide Klassen definiert. Es könnte machbar sein, vielleicht den Code duplizieren, die Klasse erweitern oder etwas anderes.

Auf der anderen Seite, das ist, was inkompatible Update-Versionen sind. Sie können versuchen, den alten Namen für immer zu unterstützen, oder Sie können dieses Erbe abschneiden und nur den neuen Namen unterstützen (warum haben Sie ihn in erster Linie geändert?).

Composer ändert die namespace Zeile im Code nicht, so dass das Präfix im Autoloader nicht geändert werden kann - es muss im Code enthalten sein. Beachten Sie außerdem, dass nur eine Klasse pro Datei zulässig ist, um mit PSR4 kompatibel zu sein, auf das von PSR1 verwiesen wird.

Was ist das Ziel dieses Versuchs? Um den alten Paketnamen für die Öffentlichkeit verfügbar zu machen, können Sie entscheiden, die alte Version ein wenig länger zu unterstützen, d. H. Funktionale und Sicherheitsfixes anzuwenden. Die neue Version würde mit einer höheren Hauptversionsnummer markiert und ebenfalls unterstützt. Ein Migrationsleitfaden würde darauf hinweisen, dass die einzige Anforderung zum Aktualisieren darin besteht, den Namespace zu ändern, sonst wäre alles gleich. Dies führt zu einem wesentlich saubereren Upgrade-Pfad, da Sie beide Versionen einzeln testen können und nicht über Eckfälle vergessen.

Auch Probleme mit type-Hinting treten nicht auf, wenn eine Klasse aus dem alten Namespace einen Typhint für die neue Klasse hat oder umgekehrt (und das ist wahrscheinlich unmöglich im Code zu ändern - zumindest ist es auch so ungewöhnlich, dass ich über eine Lösung nachdenken möchte).

TLDR: Verwenden Sie zwei Hauptversionen für die beiden Namespace-inkompatiblen Pakete, und stellen Sie dem Benutzer die einfach zu handhabenden Upgrade-Anweisungen zur Verfügung.