[BUGFIX] Avoid resolving invalid TYPO3 extensions in ComposerPackageManager
#655
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.
The
ComposerPackageManager
has been introduced to streamlinethe functional test instance creation process and provide all
selected extensions (system, custom and test fixture) within
the test instance, which original simply used relative path
names for classic mode instances or a simple extension key:
For
$coreExtensionsToLoad
:For
$testExtensionsToLoad
:With
typo3/cms-composer-installers
version 4.0RC1 and5 these paths could not be found anymore, because TYPO3
system extensions and extensions are no longer installed
into the classic paths in a composer mode instance and
left in the vendor folder, which is the case for usual
root project or extension instance.
Using the available composer information to determine the
source for extensions unrelated to the real installation
path, which can be configured with composer, was the way
to mitigate this issue and
ComposerPackageManger
hasbeen implemented to process these lookups while still
supporting test fixture extensions not loaded by the root
composer.json directly.
The implementation tried to provide backwards compatible
as much as possible along with fallback to use folder names
as extension keys by simply using
basename()
in some codeplaces and including not obvious side effects and lookup
issues.
basename()
was also used on valid composer packagenames to resolve composer package name for that value as
extension key for loaded packages, which leads to fetch the
wrong composer package.
The standlone fluid
typo3fluid/fluid
composer package nameresolved and retrieved the TYPO3 system extension package
typo3/cms-fluid
usinggetPackageInfo()
, which lead toissues in other places, for example the dependency ordering
and resolving class
PackageCollection
.This change streamlines the
ComposerPackageManager
classto mitigate building and using invalid values to lookup
extension composer package names and harden the registration
process of extension even further.
Guarding unit tests are added to cover this bugfix.
Resolves: #553
Releases: main, 8