From 7a14fa5344e09bd3988adfc9339e8f16ac5f78bd Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Stefan=20B=C3=BCrk?= <stefan@buerk.tech>
Date: Wed, 22 Jul 2026 19:16:11 +0200
Subject: [PATCH] [BUGFIX] Skip class loading info dump in Composer mode

Testbase::dumpClassLoadingInformation() is called unconditionally, also
from the unit test bootstrap, which runs in the scope of the outer
Composer installation. TYPO3 v14.3.1 changed where the classic mode
autoload information of the testing context is written: the dump
directory is now derived from Environment::getExtensionsPath(), which
resolves to "<projectRoot>/packages/ext" in Composer mode. Unit test
runs therefore create "<projectRoot>/packages/autoload-tests/",
colliding with the directory many projects use for their own local
extensions.

That dump is a no-op in Composer mode anyway, because
PackageManager::scanAvailablePackages() bails out early there and
leaves UnitTestPackageManager without any registered package. The
generated files have always been empty in that case, on v13 as well -
only their location changed, from build output to the project root.

Skip the dump in Composer mode, mirroring the guard TYPO3 Core uses on
all of its own call sites. Functional tests are unaffected:
setUpBasicTypo3Bootstrap() forces Composer mode to false, so their
instances keep receiving the class loading information they need for
their fixture extensions. The Core mono repository keeps its current
behaviour for the same reason.

Note that a "packages/autoload-tests/" directory left behind by an
earlier test run has to be removed manually once.

Resolves: #725
Releases: main, 9
---
 Classes/Core/Testbase.php | 19 ++++++++++++++++++-
 1 file changed, 18 insertions(+), 1 deletion(-)

diff --git a/Classes/Core/Testbase.php b/Classes/Core/Testbase.php
index 0a9ead77..60f7fd53 100644
--- a/Classes/Core/Testbase.php
+++ b/Classes/Core/Testbase.php
@@ -27,6 +27,7 @@
 use Psr\Container\ContainerInterface;
 use TYPO3\CMS\Core\Core\Bootstrap;
 use TYPO3\CMS\Core\Core\ClassLoadingInformation;
+use TYPO3\CMS\Core\Core\Environment;
 use TYPO3\CMS\Core\Database\Connection;
 use TYPO3\CMS\Core\Database\ConnectionPool;
 use TYPO3\CMS\Core\Database\Schema\SchemaManager\CoreSchemaManagerFactory;
@@ -764,10 +765,26 @@ public function setUpBasicTypo3Bootstrap(string $instancePath): ContainerInterfa
     }
 
     /**
-     * Dump class loading information
+     * Dump class loading information.
+     *
+     * This is only relevant for non Composer mode ("classic mode") setups, where the
+     * Composer class loader does not know about extensions: the generated files add
+     * the class map, the PSR-4 prefixes and the class alias map of all active
+     * extensions - including their `Tests/` directories - to the class loader.
+     *
+     * Functional test instances are classic mode instances by definition, so they do
+     * need the dump. Unit tests on the other hand run in the scope of the outer
+     * Composer installation, where the Composer class loader is authoritative and
+     * `PackageManager::scanAvailablePackages()` bails out early: the dump would only
+     * write empty files - into the project root ("<project>/packages/autoload-tests/"
+     * since TYPO3 v14.3.1). Skip it, mirroring the `Environment::isComposerMode()`
+     * guards TYPO3 Core uses on all of its own call sites.
      */
     public function dumpClassLoadingInformation(): void
     {
+        if (Environment::isComposerMode()) {
+            return;
+        }
         if (!ClassLoadingInformation::isClassLoadingInformationAvailable()) {
             ClassLoadingInformation::dumpClassLoadingInformation();
             ClassLoadingInformation::registerClassLoadingInformation();