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. nimcore löst dieses Problem als zentrale Basis-Library der NIM-Extension-Familie. Abstrakte Klassen, Utility-Funktionen und gemeinsame Konfiguration liegen an einer einzigen Stelle. Alle abhängigen NIM-Extensions erben von nimcore und müssen nur ihre fachliche Logik implementieren.

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. nimcore erzwingt einen einheitlichen Standard. Alle NIM-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 dem nimcore-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 nimcore. Alle abhängigen Extensions profitieren sofort, ohne dass jede einzeln angepasst werden muss. Bei einem TYPO3-v12-Upgrade mit sieben NIM-Extensions spart das typischerweise zwei bis drei Entwicklertage.

Technische Architektur folgt dem Shared-Kernel-Prinzip

nimcore registriert sich als normale TYPO3-Extension und wird über Composer als Dependency in den abhängigen Extensions deklariert. Die ext_emconf.php der NIM-Extensions listet nimcore als required constraint. Beim Installieren einer NIM-Extension wird nimcore automatisch mitgeladen.

Intern liefert nimcore 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 ermöglicht es, Extension-spezifische Einstellungen in einem einheitlichen Format zu definieren, das im TYPO3-Backend über ein Settings-Modul zugänglich ist.

Die Test-Infrastruktur ist ebenfalls in nimcore gebündelt: 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össte Risiko einer Shared-Kernel-Architektur ist der Lock-Step-Release-Zwang: Wenn nimcore ein Breaking Change einführt, müssen alle abhängigen Extensions gleichzeitig aktualisiert werden. In der Praxis bedeutet das, dass nimcore 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 nimcore abhängt und nimcore einen Service nutzt, der eigentlich in Extension A definiert ist, entsteht ein Zirkel. Die Lösung ist ein sauberes Dependency-Inversion-Prinzip: nimcore definiert Interfaces, die abhängige Extensions implementieren. nimcore selbst kennt keine konkreten Implementierungen.

Drittes Thema ist die Composer-Autoload-Reihenfolge. Bei grossen Installationen mit 30 oder mehr Extensions kann die Reihenfolge des Autoloadings dazu führen, dass nimcore-Klassen noch nicht verfügbar sind, wenn eine abhängige Extension geladen wird. Die Lösung: In der composer.json der Root-Installation nimcore als erstes in der install-order definieren.

TYPO3 v12 funktioniert, v13-Kompatibilität hängt von der Extbase-Abstraktionsschicht ab

nimcore basiert auf dem Extbase-Framework und ist damit eng an dessen API-Stabilität gekoppelt. Unter TYPO3 v12 läuft die aktuelle Version stabil. Für v13 sind Anpassungen nötig, wenn der TYPO3-Core Extbase-Interfaces ändert oder die Dependency-Injection-Konfiguration umstrukturiert.

Da nimcore ein Nischen-Produkt für die NIM-Extension-Familie ist, hängt die Weiterentwicklung direkt vom Maintainer ab. Teams, die auf nimcore setzen, sollten den Quellcode forken und in einem eigenen Repository pflegen, um nicht von externen 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.