{"id":110,"date":"2026-11-02T08:00:00","date_gmt":"2026-11-02T07:00:00","guid":{"rendered":"https:\/\/hoja.in\/blog\/composer-for-typo3-projects-path-repos-platform-and-audit\/"},"modified":"2026-10-16T14:00:13","modified_gmt":"2026-10-16T12:00:13","slug":"composer-for-typo3-projects-path-repos-platform-and-audit","status":"publish","type":"post","link":"https:\/\/hoja.in\/blog\/composer-for-typo3-projects-path-repos-platform-and-audit\/","title":{"rendered":"Composer for TYPO3 projects: path repos, platform and audit"},"content":{"rendered":"

Most TYPO3 projects I see during upgrades have the same Composer story. The core and the third-party extensions come from Packagist, fine. But the sitepackage and the two or three project extensions sit somewhere in public\/typo3conf\/ext\/<\/code>, committed directly, outside Composer. They have no version, no declared dependencies, and nobody can tell which core versions they support. Then the upgrade starts, and you find out the hard way.<\/p>\n

When I moved hoja.in from TYPO3 7.6 classic mode to a fresh 14.3 Composer project this year, I set up the Composer part so that the next upgrade is easier. These are the four pieces.<\/p>\n

1. Your own extensions as path packages<\/h2>\n

A path repository tells Composer: packages can also be found in these local folders. Each extension gets its own composer.json<\/code> with a name, a type and its requirements. This is the real root composer.json<\/code> of hoja.in, shortened:<\/p>\n

{\n    \"name\": \"harvisoft\/myport\",\n    \"type\": \"project\",\n    \"repositories\": [\n        {\n            \"type\": \"path\",\n            \"url\": \"Source\/Extension\/*\"\n        }\n    ],\n    \"require\": {\n        \"php\": \"^8.2\",\n        \"harvisoft\/sitepackage\": \"@dev\",\n        \"typo3\/cms-core\": \"^14.3\",\n        \"typo3\/cms-form\": \"^14.3\"\n    },\n    \"config\": {\n        \"platform\": {\n            \"php\": \"8.4\"\n        },\n        \"sort-packages\": true\n    },\n    \"minimum-stability\": \"stable\",\n    \"prefer-stable\": true\n}<\/code><\/pre>\n
Many projects use packages\/*<\/code> as the folder name; I used Source\/Extension\/*<\/code>. The name does not matter, the glob does: every folder with a composer.json<\/code> below it becomes an installable package. Composer symlinks it into vendor\/<\/code> (on hoja.in, vendor\/harvisoft\/sitepackage<\/code> points to ..\/..\/Source\/Extension\/sitepackage\/<\/code>), and the TYPO3 Composer installers make it an active extension.<\/p>\n
The extension’s own composer.json<\/code> declares what it really needs. For the hoja.in sitepackage that is PHP 8.2, typo3\/cms-core<\/code>, cms-fluid-styled-content<\/code>, cms-form<\/code> and cms-frontend<\/code>, all ^14.3<\/code>, plus the extra.typo3\/cms.extension-key<\/code> sitepackage<\/code>. Now the next upgrade has a clear signal: when you raise the core to v15, Composer refuses until the sitepackage says it supports v15. That is the point. The refusal is a to-do list.<\/p>\n
The @dev warning<\/h3>\n
composer validate<\/code> on hoja.in is honest with me:<\/p>\n
.\/composer.json is valid, but with a few warnings\n# General warnings\n- require.harvisoft\/sitepackage : unbound version constraints (@dev) should be avoided<\/code><\/pre>\n
The path package has no version, so Composer gives it a dev version and the root needs @dev<\/code> to accept it. If you run composer validate --strict<\/code> in CI, warnings fail the job. The cleaner way is to give the path package a version through the repository’s versions<\/code> option and require it with a normal constraint:<\/p>\n
\"repositories\": [\n    {\n        \"type\": \"path\",\n        \"url\": \"Source\/Extension\/*\",\n        \"options\": {\n            \"versions\": {\n                \"harvisoft\/sitepackage\": \"1.0.0\"\n            }\n        }\n    }\n],\n\"require\": {\n    \"harvisoft\/sitepackage\": \"^1.0\"\n}<\/code><\/pre>\n
That is on my list for hoja.in; today it still says @dev<\/code>.<\/p>\n
2. config.platform.php: resolve for production, not for your laptop<\/h2>\n
Composer resolves dependencies for the PHP version it runs on, unless you tell it otherwise. DDEV runs PHP 8.4 for hoja.in. If the hosting ran 8.2 and some package had a newer release that needs 8.3, my lock file would contain it, and production would break on the first composer install<\/code>.<\/p>\n
config.platform.php<\/code> fakes the PHP version for resolution. hoja.in pins it to 8.4, the version the hosting must provide. The runbook has a warning next to it: lower it only together with a fresh composer update<\/code>, because the setting changes what gets resolved, not what is already in the lock file.<\/p>\n
Two related habits:<\/p>\n