[BUGFIX] Skip class loading info dump in Composer mode#731
Merged
Conversation
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
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Backport of #730 to branch
9. Related: #725.Clean cherry-pick of
6073033— no adaptation needed, the code is identical on both branches.Problem
Testbase::dumpClassLoadingInformation()is called unconditionally — also fromResources/Core/Build/UnitTestsBootstrap.php, which runs in the scope of the outerComposer installation.
TYPO3 v14.3.1 changed where the classic-mode autoload information of the testing context is
written.
ClassLoadingInformation::getClassLoadingInformationDirectory()now derives thedirectory from
Environment::getExtensionsPath(), and that resolves to<projectRoot>/packages/extin Composer mode:getExtensionsPath()(Composer mode)<public>/typo3conf/ext<project>/packages/ext<public>/typo3conf/autoload-tests/<project>/packages/autoload-tests/So every unit test run creates
<projectRoot>/packages/autoload-tests/, colliding with thedirectory many projects use for their own local extensions.
Accountable Core change:
edfb03ae775/770c5383930"[TASK] Allow public folder in classicmode", forge #109470, Gerrit
93491 /
93799.
Why branch
9matters most hereBranch
9supports core v13 and v14 — it is the branch v14 users actually consume today,so it is the branch where the bug is reachable in practice. The reporter of #725 hit it with
testing-framework 9.5.0 on TYPO3 14.3.4.
No core-version-aware code needed
The guard works unchanged on both cores this branch supports:
Environment::isComposerMode()exists unchanged since v9.PackageManager::scanAvailablePackages()has the identical Composer-mode early return onv12, v13, v14 and main — verified against
v13.4.33andv14.3.5sources.So the dump was already a no-op in Composer mode on v13 (four empty files, 118/147/147/147
bytes); only the location regressed on v14.3.1, from gitignored build output to the project
root. Nothing can be lost by not writing them.
Functional tests are not affected
UnitTestsBootstrap.php(extension/project)TYPO3_COMPOSER_MODE→trueUnitTestsBootstrap.php(Core mono-repository)falseTestbase::setUpBasicTypo3Bootstrap()(all functional tests)falseTest results
Verified with this exact guard applied to the vendored testing-framework 9.6.0 in two
extensions, PHP 8.2, sqlite. Baseline (unpatched) unit runs were done first on each core, so
the before/after is on the same project rather than inferred.
web-vision/deepltranslate-core— shipsthree functional fixture extensions, the case that would break if the guard were wrong:
-s unit(baseline)packages/, dump at.Build/Web/typo3conf/autoload-tests/-s unit(patched)packages/-s functional(patched)-s unit(baseline)packages/autoload-tests/created, four empty files-s unit(patched)packages/-s functional(patched)Functional instances still receive the full classic-mode dump, including the fixture extension
and all
Tests/directories:plus 100 class map entries.
web-vision/deepl-write:-s unitpackages/(before: created)-s functional-s unitpackages/-s functionalTYPO3 Core mono-repository (
main, v15-dev), PHP 8.4 — behaviour unchanged, mono-repo isclassic mode:
-s unit -- --filter GeneralUtilityTesttypo3conf/autoload-tests/still written-d sqlite -s functional -- typo3/sysext/core/Tests/Functional/Package/-d sqlite -s functional -- typo3/sysext/extbase/Tests/Functional/Persistence/This branch's own gates, PHP 8.2:
-s composerUpdate-s cgl -n-s lint-s phpstan-s unitNote for users
A
packages/autoload-tests/directory left behind by an earlier test run has to be removedmanually once — this change only stops new ones from being created.