Grundsätzlich halte ich diesen Schritt für sinnvoll und richtig, da es nun einen zentralen Ort gibt, an dem man sich als TYPO3-Nutzer über (fast) alle existierende TYPO3 Extensions informieren kann. Ich sehe es mittlerweile aber so, dass hier noch ein wenig Nachbesserung bei der Implementierung nötig ist, da es meistens einen Unterschied gibt zwischen Extensions, die bewusst vom Entwickler im TYPO3 Extension Repository (TER) veröffentlicht wurden und denjenigen, die ausschließlich auf packagist.org veröffentlicht wurden.
Wer detaillierte Informationen zur aktuellen Umsetzung nachlesen will kann direkt ins Feature-Ticket rein schauen:
https://git.typo3.org/services/t3o-sites/extensions.typo3.org/ter/-/merge_requests/755
Es werden nun also regelmäßig Paketname, Paketdaten und Importdatum von Composer Packages, die den Typ typo3-cms-extension nutzen und nicht explizit im TER veröffentlicht wurden, über die Packagist API ermittelt und im TER gelistet. Die Typ-Angabe typo3-cms-extension wird von "TYPO3 CMS Composer installers" typo3/cms-composer-installers (einem TYPO3 Core Requirement) vorgegeben, um es einem Composer-Package zu ermöglichen, als TYPO3 Extension in TYPO3 installiert werden zu können.
https://github.com/TYPO3/CmsComposerInstallers
Mit diesem Filter konnten also jegliche TYPO3 Extensions, die Composer nutzen UND auf packagist.org veröffentlicht wurden, identifiziert werden.
Ich habe den Eindruck, dass die Veröffentlichung im TER für die meisten Entwickler auch mit der Voraussetzung zusammenhängt, dass sie ihren Code für die Allgemeinheit zugänglich gemacht haben, also sich um eine gute Dokumentation gekümmert haben und, wo möglich, sich um eine flexible Konfigurierbarkeit Gedanken gemacht haben.
Warum ist das bei Extensions manchmal nicht der Fall, die nur auf packagist.org veröffentlicht wurden? Ich würde mir das so erklären, dass Entwickler auch Extensions dort hochladen, die für den "Eigenbedarf" gedacht sind, um vom einfachen Installationsprozess profitieren zu können. Statt das Git-Repository zu clonen wird nur noch der Packagename mit Versionsangabe in die composer.json geschrieben.
Das gleiche könnte man auch erreichen über ein privates PHP Package Repository, quasi ein self-hostet Packagist, aber entweder die Entwickler haben diese Möglichkeit garnicht auf dem Schirm oder scheuen den Aufwand so etwas zusätzich einzurichten. Schließlich klappt's ja genauso gut mit packagist.org 😋.
Vielleicht erfolgte der Upload auf packagist.org auch aus dem Grund, dass zumindest der Wunsch besteht in unbestimmter Zukunft das "Eigenbedarf"-Package nachträglich für die Allgemeinheit aufzupolieren.
Ich vermute aber auch, dass manche Entwickler dem TER nicht ganz so viel Bedeutung zurechnen und laden selbst gut dokumentierte Extensions, die einen echten Mehrwert für die Allgemeinheit bringen würden, nicht dort hoch. Es ist ja auch nochmal ein zusätzlicher Publishing-Prozess, sofern man das nicht bereits über das TER REST-Interface automatisiert hat.
Fazit
Die Gründe für das Upload-Verhalten sind ebenso vielfältig wie die Qualität und Nutzbarkeit der betroffenen Packages. Sollte man deshalb ALLE Packages, die nicht extra ins TER geladen wurden, ignorieren? Ich finde nicht. Der Normalverbraucher kennt doch normalerweise nicht die ganzen Orte, an denen man TYPO3 Extensions finden kann. Habt ihr jemals auf packagist.org nach dem Package-Typ typo3-cms-extension gefiltert, um dort explizit TYPO3 Extensions zu finden?
https://packagist.org/explore/?type=typo3-cms-extension
Ich selbst habe das jedenfalls bisher nicht. Mein erster und meist letzter Gang geht über das TER. Meine Extension feed_display
https://extensions.typo3.org/extension/feed_display
wäre vielleicht garnicht entstanden, wenn ich damals die Extension newssync von Kay Strobach gefunden hätte
https://extensions.typo3.org/package/kaystrobach/newssync
Die Extension easy_slug nutzt Xavier Perseguers bereits seit ein paar Jahren produktiv aber hat sich bisher nicht getraut sie ins TER zu laden.
https://twitter.com/xperseguers/status/1735693663378821142
Ist sie ausreichend dokumentiert? Nein. Bietet sie einen Mehrwert? Ja.
Welche Nachbesserungen wären also noch nötig?
Explizite Kennzeichnung der reinen von packagist.org importierten Extensions
Ich finde es geht nun darum, dem TYPO3-Nutzer im TER kenntlich zu machen, ob die Extension vom Entwickler explizit zugänglich gemacht wurde oder nicht. In letzterem Fall ist man eben als Anwender mehr gefragt und sollte das auf dem Schirm haben. Man muss im Zweifel den undokumentierten Code lesen und verstehen können, um ihn sinnvoll selbst nutzen zu können. Außerdem muss man sich bewusst machen, dass der Entwickler dieser Extension im Zweifel nicht auf dem Schirm hat, dass sie noch von anderen genutzt wird. Es kann hier also ein etwas anderes Verantwortungsgefühl hinsichtlich der Wartung der Extension geben.
Was aktuell noch fehlt ist eine Möglichkeit genau diese Extensions im TER heraus zu filtern bzw. zu kennzeichnen, um keine falschen Erwartungen beim Nutzer hervor zu rufen. Wir haben zwar eine neue Möglichkeit nach "Installation method" → "Composer" zu filtern sowie nach "Composer support" (Unterschied erschließt sich mir nicht wirklich) aber wir haben keine Möglichkeit innerhalb der Composer-Packages diejenigen zu filtern, die nicht explizit ins TER geladen wurden. Es bräuchte einen "officially published" Marker oder etwas vergleichbares.
Aktuell erkennt man die betroffenen Packages eigentlich nur am Default-Icon. Im TER veröffentlichte Extensions, die kein Extension-Icon mitbringen, werden auch ohne ein Icon gelistet. Die Wahrscheinlichkeit ist also hoch, dass das Default-Icon ein importiertes Package kennzeichnet, wenn das Icon nicht explizit vom Entwickler in seiner TER-Veröffentlichung verwendet wurde.
Entfernen veralteter TER-Extensions, die nurnoch auf packagist.org weiter gepflegt werden
Laut einer Aussage im Feature-Ticket von Garvin Hicking scheint es auch so zu sein, dass manche im TER gelistete Erweiterungen veraltet sind aber auf Packagist weiter gepflegt werden. In diesen Fällen würde der automatische Import nicht greifen. Hier wäre es sinnvoll, die veraltete TER-Version zu entfernen, um im TER per Import den neuesten Stand wieder sichtbar zu machen.