nimcore für TYPO3

Ohne zentrale Basis-Library erzeugen Extension-Familien doppelten Code und doppelte Fehler

TYPO3-Agenturen, die mehrere zusammengehörige Extensions entwickeln, stehen vor einem Architekturproblem: Jede Extension reimplementiert Utility-Funktionen wie Konfigurationsauslese, Backend-Module-Registrierung, FAL-Handling und Logging. Bei fünf Extensions bedeutet das fünf Kopien derselben Hilfsfunktionen, fünf Stellen für denselben Bug. Die Lösung ist eine zentrale Basis-Library: Abstrakte Klassen, Utility-Funktionen und gemeinsame Konfiguration liegen an einer einzigen Stelle, und alle abhängigen Extensions erben davon und müssen nur ihre fachliche Logik implementieren. nimcore ist als eine solche Library für die NIM-Extensions benannt, aber weder im TER noch auf Packagist oder GitHub veröffentlicht; was sie enthält, lässt sich deshalb nicht prüfen.

Dieses Pattern ist im TYPO3-Ökosystem selten, aber in der Software-Architektur etabliert: Ein Shared Kernel, der horizontale Concerns (Logging, Configuration, Base Models) kapselt, während vertikale Extensions (Audio Player, Galerie, Slider) die Fachlogik übernehmen.

Typische Einsatzszenarien betreffen Agenturen mit eigenen Extension-Portfolios

Das primäre Szenario ist die Agentur, die ein Set von vier bis zehn eigenen TYPO3-Extensions pflegt. Ohne eine gemeinsame Basis-Library wachsen die Extensions auseinander: Die eine nutzt GeneralUtility::makeInstance, die andere den DI-Container, die dritte hat eine eigene Logger-Konfiguration. Eine gemeinsame Basis-Library erzwingt einen einheitlichen Standard: Alle Extensions nutzen dieselben abstrakten Controller-Klassen, dasselbe Exception-Handling und dieselbe Konfigurationsstruktur.

Ein zweites Szenario sind Inhouse-Entwicklungsteams, die ihre TYPO3-Instanz mit mehreren Custom-Extensions erweitern. Statt jede Extension als isoliertes Paket zu behandeln, können Teams eine eigene Core-Library nach diesem Muster aufbauen: gemeinsame Base-Models, gemeinsame Backend-Module-Klassen, gemeinsame Test-Fixtures. Das reduziert den Wartungsaufwand und senkt die Einstiegshürde für neue Entwickler, die nur eine Architektur lernen müssen.

Ein drittes Szenario ist die Versionierung bei Upgrades. Wenn der TYPO3-Core eine API ändert, die in fünf Extensions genutzt wird, genügt ein einziges Update in der Basis-Library. Alle abhängigen Extensions profitieren sofort, ohne dass jede einzeln angepasst werden muss. Bei einem TYPO3-v12-Upgrade mit sieben abhängigen Extensions spart das typischerweise zwei bis drei Entwicklertage.

Technische Architektur folgt dem Shared-Kernel-Prinzip

Eine solche Basis-Library registriert sich als normale TYPO3-Extension und wird über Composer als Dependency in den abhängigen Extensions deklariert; deren ext_emconf.php listet sie als required constraint. Beim Installieren einer abhängigen Extension wird die Library automatisch mitgeladen.

Intern liefert sie abstrakte Klassen für Controller, Repositories und Models, die das TYPO3-Extbase-Framework korrekt initialisieren. Utility-Klassen kapseln wiederkehrende Aufgaben: TypoScript-Konfiguration auslesen, FAL-Referenzen auflösen, Backend-Toolbars registrieren, Flash-Messages standardisiert ausgeben. Eine zentrale Configuration-Registry kann es ermöglichen, Extension-spezifische Einstellungen in einem einheitlichen Format zu definieren, das im TYPO3-Backend über ein Settings-Modul zugänglich ist.

Auch die Test-Infrastruktur lässt sich dort bündeln: Base-TestCase-Klassen, Fixture-Loader und Mocking-Utilities, die funktionale Tests für Extbase-Extensions vereinfachen. Das senkt die Hürde, Tests zu schreiben, weil das Setup nicht in jeder Extension neu konfiguriert werden muss.

Häufige Probleme entstehen bei Versions-Konflikten und zirkulären Abhängigkeiten

Das größte Risiko einer Shared-Kernel-Architektur ist der Lock-Step-Release-Zwang: Wenn die Basis-Library ein Breaking Change einführt, müssen alle abhängigen Extensions gleichzeitig aktualisiert werden. In der Praxis bedeutet das, dass sie semantic versioning strikt einhalten muss. Minor-Versionen dürfen keine öffentlichen Interfaces ändern, und Major-Releases brauchen eine Migrationsanleitung.

Zweites Problem: zirkuläre Abhängigkeiten. Wenn Extension A von der Basis-Library abhängt und die Library einen Service nutzt, der eigentlich in Extension A definiert ist, entsteht ein Zirkel. Die Lösung ist ein sauberes Dependency-Inversion-Prinzip: Die Library definiert Interfaces, die abhängige Extensions implementieren, und kennt selbst keine konkreten Implementierungen.

Drittes Thema ist die Ladereihenfolge der Extensions. Bei großen Installationen mit 30 oder mehr Extensions kann eine abhängige Extension die Konfiguration der Basis-Library erwarten, bevor diese geladen ist. Die Lösung: die Library in der composer.json jeder Extension, die sie nutzt, unter require eintragen. Daraus leitet TYPO3 im Composer-Modus die Ladereihenfolge ab; die Klassen selbst lädt der Composer-Autoloader ohnehin erst beim ersten Zugriff.

nimcore ist nicht öffentlich verfügbar, das Muster lässt sich selbst umsetzen

nimcore ist weder im TER noch auf Packagist oder GitHub veröffentlicht; welche TYPO3-Versionen nimcore unterstützt, lässt sich deshalb nicht prüfen. Eine Basis-Library auf Extbase-Grundlage ist eng an dessen API-Stabilität gekoppelt: Ändert der TYPO3-Core Extbase-Interfaces oder die Dependency-Injection-Konfiguration, muss sie mit jeder Hauptversion angepasst werden.

Weil nimcore nicht öffentlich gepflegt wird, hängt jede Weiterentwicklung an denen, die den Quellcode haben. Teams, die nimcore im Bestand einsetzen, sollten den Quellcode in einem eigenen Repository pflegen, um nicht von fremden Release-Zyklen abhängig zu sein. Gosign empfiehlt bei Custom-Extension-Portfolios generell, die Shared-Kernel-Architektur intern aufzubauen und unter eigener Kontrolle zu halten, statt auf externe Core-Libraries zu vertrauen.