Ich habe ein Projekt, das unter anderem die folgenden composer.json Abhängigkeiten enthält:
Ich habe kürzlich eine composer update gemacht und festgestellt, dass eine neue Version einer von PhpMetrics benötigten Bibliothek namens Hoa eine neue Klasse \EngineException einführt, um eine neue PHP7 Klasse zu emulieren. Leider definiert Propel 1 auch \EngineException , und so entsteht ein Konflikt.
Die richtige Lösung wäre ein Upgrade auf Propel 2, das Namespaces verwendet. Allerdings ist dies immer noch in Alpha und unterliegt BC Pausen, so ist nicht wirklich für mich praktikabel.
Mein momentaner Fix ist, Hoa auf eine bestimmte Version zu sperren, die nicht die neue Klasse hat:
%Vor%Das ist keine schlechte Lösung, aber es ist nicht ganz befriedigend, eine Bibliothek auf eine alte Version zu sperren.
Im Hoa-Code kann die neue Klasse nur dann nicht geladen werden, wenn PHP 7 ausgeführt wird, was wiederum nicht möglich ist. Es fällt mir aber auch ein, dass Hoa nur require d sein muss, wenn PhpMetrics läuft. Dies ist ein Standalone-Code-Analyse-Tool und sitzt nur im Wurzel des Projekts aus Bequemlichkeit; Der Rest des Projekts verwendet diese Bibliothek nicht.
Es wäre also großartig, wenn ich etwas in Composer aufrufen könnte, um zu fragen, dass diese Klasse nicht (automatisch) geladen wird, oder vielleicht etwas, das in composer.json gleich ist. Es wird derzeit unnötigerweise geladen - ich weiß nicht, ob es nicht automatisch geladen wird oder ob es require d manuell von Composer ist.
Es kann hilfreich sein zu wissen, dass Hoa-Klassen von Composer zum automatisch generierten Skript autoload_psr4.php hinzugefügt wurden. Soweit ich die Dokumente verstehen kann , heißt das, dass es automatisch geladen wird und nichts darin ist mein Projekt, das einen der Hoa-Klassen erfordern würde.
Ich war neugierig, also habe ich nachgesehen. Hoa hat tatsächlich einen kaputten Ansatz, bei dem die Datei Core.php immer enthalten ist, durch eine " Datei "Autoload" im Composer, die wiederum Consistency.php enthält. Letzteres definiert Ihre Klasse.
Du könntest ein Problem mit den Entwicklern von Hoa melden, um class_exists um nach der Methode und nicht nach der Versionskontrolle zu suchen, die sie verwenden. Dies könnte dazu führen, dass der prop-Autoloader geladen wird. Ein anderer Weg wäre, das Autoloading korrekt zu definieren, aber sie ziehen es vor, manuell zu laden, wie es scheint.
Behoben von Ссылка .
Die neue Ausnahmearchitektur, die in PHP7 [1] eingeführt wurde, war vollständig neu gestaltet [2]. Dieser Patch aktualisiert die Retro-Kompatibilitätsklassen nach dieser neuen Architektur. Folglich ist
BaseExceptionKlasse wurde entfernt, zusammen mitEngineExceptionund %Code%. Während diese letzteren implementiert werden könnten (nicht als ist), wir bevorzugen, bis jetzt nur dieParseExceptionSchnittstelle zu implementieren. Mal sehen ob wir (noch für die Retro-Kompatibilität) das umsetzen könnenThrowable,ErrorundTypeErrorklasse.[1]: Ссылка
[2]: rfc / throwable-interface
Tags und Links php composer-php