nimcore for TYPO3

Without a central base library, extension families duplicate their code and their bugs

TYPO3 agencies that develop several related extensions run into an architectural problem: every extension reimplements utility functions such as reading configuration, registering backend modules, FAL handling and logging. With five extensions, that means five copies of the same helper functions and five places for the same bug. The solution is a central base library: abstract classes, utility functions and shared configuration live in a single place, and all dependent extensions build on it and only need to implement their domain logic. nimcore is named as such a library for the NIM extensions but is published neither in the TER nor on Packagist or GitHub, so what it contains cannot be verified.

The pattern is rare in the TYPO3 ecosystem but well established in software architecture: a shared kernel encapsulates the horizontal concerns (logging, configuration, base models), while vertical extensions (audio player, gallery, slider) handle the domain logic.

Typical use cases involve agencies with their own extension portfolios

The primary scenario is the agency that maintains a set of four to ten TYPO3 extensions of its own. Without a shared base library, the extensions drift apart: one uses GeneralUtility::makeInstance, another the DI container, a third has its own logger configuration. A shared base library enforces a uniform standard: all extensions use the same abstract controller classes, the same exception handling and the same configuration structure.

A second scenario is in-house development teams that extend their TYPO3 instance with several custom extensions. Instead of treating each extension as an isolated package, teams can build their own core library following this pattern: shared base models, shared backend module classes, shared test fixtures. This reduces maintenance effort and lowers the barrier for new developers, who only have to learn one architecture.

A third scenario is versioning during upgrades. When the TYPO3 core changes an API used in five extensions, a single update in the base library is enough. All dependent extensions benefit immediately, without each one having to be adapted individually. For a TYPO3 v12 upgrade with seven dependent extensions, that typically saves two to three developer days.

The technical architecture follows the shared kernel principle

Such a base library registers as a regular TYPO3 extension and is declared as a Composer dependency in the extensions that rely on it; their ext_emconf.php lists it as a required constraint. When a dependent extension is installed, the library is loaded automatically along with it.

Internally, it provides abstract classes for controllers, repositories and models that initialize the TYPO3 Extbase framework correctly. Utility classes encapsulate recurring tasks: reading TypoScript configuration, resolving FAL references, registering backend toolbars and issuing flash messages in a standardized way. A central configuration registry can let each extension define its settings in a uniform format that is accessible in the TYPO3 backend through a settings module.

The test infrastructure can be bundled there as well: base TestCase classes, fixture loaders and mocking utilities that simplify functional tests for Extbase extensions. This lowers the barrier to writing tests, because the setup does not have to be configured anew in every extension.

Common problems stem from version conflicts and circular dependencies

The biggest risk of a shared kernel architecture is being forced into lock-step releases. When the base library introduces a breaking change, all dependent extensions have to be updated at the same time. In practice, this means it must adhere strictly to semantic versioning: minor versions must not change public interfaces, and major releases need a migration guide.

The second problem is circular dependencies. If extension A depends on the base library and the library uses a service that is actually defined in extension A, the result is a cycle. The solution is a clean application of the dependency inversion principle: the library defines interfaces that dependent extensions implement, and it knows no concrete implementations itself.

The third topic is the loading order of the extensions. In large installations with 30 or more extensions, a dependent extension can expect the base library’s configuration before the library has been loaded. The fix: list the library under require in the composer.json of every extension that uses it. In Composer mode, TYPO3 derives the loading order from these dependencies; the classes themselves are only loaded by the Composer autoloader when they are first used.

nimcore is not publicly available, but the pattern can be implemented in-house

nimcore is published neither in the TER nor on Packagist or GitHub, so which TYPO3 versions it supports cannot be verified. A base library built on Extbase is tightly coupled to the stability of the Extbase API: if the TYPO3 core changes Extbase interfaces or the dependency injection configuration, the library has to be adapted with every major version.

Because nimcore is not maintained publicly, any further development depends on whoever has the source code. Teams that already run nimcore should maintain the source code in their own repository so they do not depend on outside release cycles. For custom extension portfolios, Gosign generally recommends building the shared kernel architecture in-house and keeping it under your own control rather than relying on external core libraries.