Streamline `ComposerPackageManager->getPackageInfo()` usage to support extensions with none matching folder name

[d-s-codappix]

What are you trying to achieve?

We have one TYPO3 installation as a mono repository.
This provides extensions for different TYPO3 installations, installed via composer during deployment.
Those have tests, specific to their installations.
Those extensions have a different folder name compared to their extension name, for historic reasons.

We now want to add this extensions to $this->testExtensionsToLoad within an FunctionalTestCase.

What do you get instead?

TYPO3\CMS\Core\Package\Exception\InvalidPackagePathException: Tried to instantiate a package object for package "client_clientname" with a non-existing package path "/var/projects/company/customers/client/monorepo/client/public/typo3temp/var/tests/functional-3646e63/typo3conf/ext/client_clientname/". Either the package does not exist anymore, or the code creating this object contains an error.

/var/projects/company/customers/client/monorepo/client/vendor/typo3/cms-core/Classes/Package/Package.php:105
/var/projects/company/customers/client/monorepo/client/vendor/typo3/testing-framework/Classes/Core/PackageCollection.php:92
/var/projects/company/customers/client/monorepo/client/vendor/typo3/testing-framework/Classes/Core/Testbase.php:637
/var/projects/company/customers/client/monorepo/client/vendor/typo3/testing-framework/Classes/Core/Functional/FunctionalTestCase.php:365
/var/projects/company/customers/client/monorepo/client/local_packages/custom_core/Tests/Functional/AbstractClientSpecificFrontendRenderingTestCase.php:33
/var/projects/company/customers/client/monorepo/client/vendor/bin/phpunit:122

How to reproduce the issue?

1. Create a new TYPO3 installation with TYPO3 testing framework
2. Create a local composer package, that is not required via projects composer.json. It has a different extra.typo3/cms.extension-key than its own folder name.
3. Create functional test within this composer package via $this->testExtensionsToLoad[] = __DIR__ .. The extension key won't work, as composer isn't aware of it.

Additional information you would like to provide?

We fixed it by streamlinining the usage of the existing API:

diff --git a/Classes/Core/Testbase.php b/Classes/Core/Testbase.php
index 9b04635..4192ad7 100644
--- a/Classes/Core/Testbase.php
+++ b/Classes/Core/Testbase.php
@@ -606,7 +606,7 @@ class Testbase
 
         // Activate test extensions that have been symlinked before
         foreach ($testExtensionPaths as $extensionPath) {
-            if ($packageInfo = $this->composerPackageManager->getPackageInfo($extensionPath)) {
+            if ($packageInfo = $this->composerPackageManager->getPackageInfoWithFallback($extensionPath)) {
                 $extensionName = $packageInfo->getExtensionKey();
             } else {
                 $extensionName = basename($extensionPath);

That way it will use the same logic, to determine extension key from composer.json at given path, instead of falling back to basename of path, the same as within linkTestExtensionsToInstance().

Specify some data of the environment

• TYPO3 testing framework version: 8.2.0
• TYPO3 version: 12.4.26
• TYPO3 installation type: composer
• PHP version: 8.2.29
• Web server used + version: FunctionalTest
• Operating system: NixOS
• Selenium server version: FunctionalTest
• Browser driver (chromedriver/geckodriver...) version: FunctionalTest
• Browser used + version: FunctionalTest

[d-s-codappix]

I remember there was a movement to get rid of the paths and only support composer package names, not sure what needs to be done to finish this. Maybe there is an API within composer to install the required package, following composer logic, which would find it in configured local file paths? Instead of only checking installed packages, or file system manually.

[sbuerk]

I remember there was a movement to get rid of the paths and only support composer package names, not sure what needs to be done to finish this. Maybe there is an API within composer to install the required package, following composer logic, which would find it in configured local file paths? Instead of only checking installed packages, or file system manually.

I have a composer plugin which helps with that, determining these "fixture extensions" and allow to simply use the "composer package" name of it. Needed that mysel so implemented it as experimental/poc. That plugin also helps with test fixture namespace registration removing the need to redo it in the root composer.json if done in test-fixture composer.json. It requires to add a small snippet to the functional bootstrap. You may try: https://github.com/sbuerk/fixture-packages

We are using that successfully in projects and also extensions development (extensions monorepo),
for example https://github.com/fgtclb/academic-extensions/blob/6e33e44223aea4b83b5146d45c09f41d1f9ae221/composer.json#L35-L43

---

Regarding the issue/suggestion I'm going to look into that the next days. Thanks for reporting it.