Feature: #108345 - Allow extensions without ext_emconf.php in classic mode 

Extension title and description 

See Feature: #108653 - Database storage for form extension for how the extension title and description can be set individually in composer.json.

Extension version 

The version number can be set in extra.typo3/cms.version or alternatively in the "version" field in composer.json.

For third-party extensions to be compatible with TYPO3 classic mode, this version must now be set to the same version previously defined in ext_emconf.php and should match the version in the Git tag, for example when publishing to Packagist.

Fixture extensions used in tests can set any version number, for example 1.0.0, but a version number must still be provided to avoid deprecation messages. During testing the version number is not evaluated.

TYPO3 Core extensions may omit the version number in composer.json because their version number is derived via \TYPO3\CMS\Core\Information\Typo3Version .

Extension state and update exclusion 

The former state property in ext_emconf.php was used for multiple purposes. In composer.json, this is now represented by dedicated metadata instead of a single field.

Supported extension stability values are expressed as version suffixes, for example:

{
    "name": "vendor/example",
    "type": "typo3-cms-extension",
    "description": "Example extension",
    "extra": {
        "typo3/cms": {
            "extension-key": "example_extension",
            "version": "1.2.3-alpha4",
            "Package": {
                "providesPackages": {}
            }
        }
    }
}

Supported Composer stability values are:

• dev
• alpha
• beta
• RC
• stable

For example:

• 1.2.3-dev
• 1.2.3-alpha1
• 1.2.3-beta2
• 1.2.3-RC3
• 1.2.3

Values from the former state field that are not supported by Composer stability can be expressed as build metadata by appending +... to the version string.

Example:

{
    "name": "vendor/example",
    "type": "typo3-cms-extension",
    "description": "Example extension",
    "extra": {
        "typo3/cms": {
            "extension-key": "example_extension",
            "version": "1.4.2+obsolete",
            "Package": {
                "providesPackages": {}
            }
        }
    }
}

In this example, TYPO3 will treat the version as 1.0.0, keep obsolete as build metadata, and expose it in the Extension Manager.

The former state = excludeFromUpdates value from ext_emconf.php is now represented by a dedicated boolean flag in composer.json:

{
    "name": "vendor/example",
    "type": "typo3-cms-extension",
    "description": "Example extension",
    "extra": {
        "typo3/cms": {
            "extension-key": "example_extension",
            "version": "1.2.3",
            "exclude-from-updates": true,
            "Package": {
                "providesPackages": {}
            }
        }
    }
}

This replaces overloading the former state field for update handling.

Dependencies on other TYPO3 extensions 

ext_emconf.php had a property for specifying dependencies on other extensions by referencing the extension key and an optional range of versions.

composer.json also contains a field for specifying dependencies using a Composer package name with a version range. However, there is no direct way to distinguish whether such a package name refers to another TYPO3 extension or to a regular Composer package that should be installed from Packagist.

TYPO3, however, needs to know which other extensions an extension depends on in order to resolve the extension loading order correctly.

Therefore, TYPO3 must know which package names refer to TYPO3 extensions and which refer to regular Composer packages. In Composer mode, this can be resolved automatically.

In classic mode, TYPO3 now recognizes several categories:

• TYPO3 framework packages shipped by the core
• Composer packages already installed and shipped with TYPO3
• Composer packages provided by other loaded extensions via providesPackages

Because of this, extension authors do not need to repeat such package names in providesPackages.

Extensions still need to declare Composer packages that they themselves provide when loaded in classic mode. For those entries, providesPackages can also define a relative path to a Composer vendor directory. If that directory contains a Composer-generated autoload.php, TYPO3 includes it early during bootstrap.

This makes it possible to both declare Composer packages and bootstrap their autoloader in a standardized way.

Here is an example of an extension that ships a local Composer vendor directory:

{
    "name": "vendor/example",
    "type": "typo3-cms-extension",
    "description": "Example extension",
    "license": "GPL-2.0-or-later",
    "require": {
        "typo3/cms-core": "^14.2",
        "vendor/other-example": "*",
        "symfony/dotenv": "^8.0"
    },
    "extra": {
        "typo3/cms": {
            "extension-key": "example_extension",
            "version": "1.2.3",
            "Package": {
                "providesPackages": {
                    "symfony/dotenv": "Resources/Private/Php/ComposerVendor"
                }
            }
        }
    }
}

In this example, the package symfony/dotenv is provided by the extension itself in TYPO3 classic mode, and TYPO3 will include Resources/Private/Php/ComposerVendor/autoload.php early if it is a Composer-generated autoload file.

The Composer package names typo3/cms-core and vendor/other-example are assumed to refer to TYPO3 extensions, and TYPO3 guarantees that vendor/example is loaded after vendor/other-example. Otherwise, an error is thrown if the extension vendor/other-example does not exist in the system.

Packages that are already shipped by TYPO3 or already provided by another loaded extension do not need to be listed in providesPackages.

Even if an extension does not depend on any Composer packages, it is still required to specify providesPackages in composer.json as an empty object to ensure future compatibility with TYPO3 classic mode and to avoid deprecation messages in TYPO3 v14.

{
    "name": "vendor/example",
    "type": "typo3-cms-extension",
    "description": "Example extension",
    "license": "GPL-2.0-or-later",
    "require": {
        "typo3/cms-core": "^14.2",
        "vendor/other-example": "*"
    },
    "extra": {
        "typo3/cms": {
            "extension-key": "example_extension",
            "version": "1.2.3",
            "Package": {
                "providesPackages": {}
            }
        }
    }
}

PHP version constraints 

PHP version constraints from ext_emconf.php can also be represented in the require section of composer.json.

Example:

{
    "name": "vendor/example",
    "type": "typo3-cms-extension",
    "description": "Example extension",
    "require": {
        "typo3/cms-core": "^14.2",
        "php": "^8.2"
    },
    "extra": {
        "typo3/cms": {
            "extension-key": "example_extension",
            "version": "1.5.6",
            "Package": {
                "providesPackages": {}
            }
        }
    }
}

The PHP dependency is kept as package metadata so TYPO3 classic mode can still evaluate PHP version requirements. However, it is ignored for extension dependency ordering.

Be aware that keeping ext_emconf.php, while no longer directly required by TYPO3, may still be necessary for some tools, such as Tailor or TYPO3 TER. Therefore, for the time being, it is recommended to keep the file and ensure that its information stays in sync with composer.json as outlined above.

However, TYPO3 will not evaluate ext_emconf.php anymore if the required metadata is correctly defined in composer.json and package metadata can be derived from it.