phpBB Ext Check - Diskussion bezüglich Prozedur und Reports

[LukeWCS]

Hi Udo

Warum wird in der composer nicht die korrekte Zeile sondern jenes In Factory.php line 317 angezeigt?

Das hat mich anfangs auch irritiert, bis ich mir das genauer angeschaut habe. Der Shell Befehl composer validate, der hier ausgeführt wird, steuert eine ganze Reihe verschiedener Module (PHP Dateien) und die gelbe Zeile mit

In {datei}.php line {zeile}:

zeigt einfach den Namen des Composer Moduls und die genaue Zeile an, wo die Meldung erzeugt wurde. Diese gelbe Zeile ganz am Anfang können wir also ignorieren.

Nun, im ersten Test von heute dauerte es ein wenig länger (blaufarbene Ladebalken) und im zweiten Test derselben EXT lief der Check rasant durch.
Wobei es sich ja eher um eine "MINI-EXT" im Vergleich zu anderen Extensionen handelt.

Ja, weil bei deiner ersten Prüfung lief von einem anderen Entwickler 30 Minuten vorher schon eine Prüfung. Bei deiner zweiten war 3 Minuten vorher schon eine Prüfung. Es hängt also stark vom System Cache ab, wie schnell das Tool ausgeführt wird. Die Grösse der Ext ist dabei irrelevant.

Bisher habe ich bei EC Laufzeiten bei Composer Validator von 100ms bis 11.5s gesehen. Im Prinzip ist alles bis maximal 2-3s okay. 11 Sekunden sind jedenfalls viel zu viel. Mal sehen was ich hier noch mache.

[Kirk]

OK danke für die Info, man war es z. B. von EPV anders gewohnt. Was die Laufzeit angeht, beim ersten Check waren es ca. 8 und beim zweiten ca. 4 Sek.

[LukeWCS]

EC 1.10.0 ist live

Obwohl es im Changelog eher beiläufig erwähnt wird, war in den letzten Wochen die umfangreiche Optimierung und Modernisierung des PHP Codes tatsächlich der Schwerpunkt des Updates, mit dem ich kurz nach 1.9.5 begonnen hatte. Seit 1.9.1 hat sich die PHP Mindestversion zweimal geändert; von 7.1 auf 7.4 und nun auf 8.0. Daneben gab es auch wieder Fixes sowie kleinere Detailverbesserungen.

[LukeWCS]

Gerade gesehen, das am 16.9 CodeSniffer 4.0 veröffentlicht wurde. Ich werde bei EC also als nächstes den Wechsel auf CS 4.0 vollziehen, vorausgesetzt, dass alle Prüftools bereits dafür ausgelegt sind. Bei PHPC sehe ich da keine Probleme am Horizont, stammt ja von derselben Quelle wie CS. Probleme könnte VariableAnalysis machen.

edit: Und PPSSE macht auch keine Probleme, da ich die Inkompatibilität frühzeitig gemeldet hatte und das schon angepasst wurde.

[LukeWCS]

Vermutung hat sich bestätigt, VA ist noch nicht kompatibel mit CS 4.0:

Code: Alles auswählen

Loading composer repositories with package information
Updating dependencies
Your requirements could not be resolved to an installable set of packages.

  Problem 1
    - Root composer.json requires sirbrillig/phpcs-variable-analysis ^2.12 -> satisfiable by sirbrillig/phpcs-variable-analysis[v2.12.0].
    - sirbrillig/phpcs-variable-analysis v2.12.0 requires squizlabs/php_codesniffer ^3.5.6 -> found squizlabs/php_codesniffer[3.5.6, ..., 3.13.4] but it conflicts with your root composer.json require (^4.0).

Use the option --with-all-dependencies (-W) to allow upgrades, downgrades and removals for packages currently locked to specific versions.

Anfrage beim Entwickler ist gestellt:

https://github.com/sirbrillig/phpcs-var ... issues/355

[LukeWCS]

Payton Swick hat rasend schnell reagiert, VA ist jetzt auch in trockenen Tüchern, was CS 4 angeht.

Leider ist es trotzdem nicht mit einem simplen Composer Update getan. Ich muss alle EC Prüfmodule die mit CS arbeiten, also PPSSE, PHPC und VA, noch explizit an CS 4 anpassen, da es sonst bei Exts ohne Befund zu einer falschen Anzeige in der Übersicht kommt. Und bei Exts die gar keine PHP Dateien haben, wird sogar die Exception-Mechanik von EC getriggert, also Ausnahmefehler ausgelöst, inklusive Warnung im Bericht und Sichern der Ext in den Failed-Ordner.