Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Conversation

sbuerk
Copy link
Collaborator

@sbuerk sbuerk commented Nov 28, 2024

The ComposerPackageManager has been introduced to streamline
the 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:

  • typo3/sysext/backend
  • backend

For $testExtensionsToLoad:

  • typo3conf/ext/my_ext_key
  • my_ext_key

With typo3/cms-composer-installers version 4.0RC1 and
5 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 has
been 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 code
places and including not obvious side effects and lookup
issues. basename() was also used on valid composer package
names 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 name
resolved and retrieved the TYPO3 system extension package
typo3/cms-fluid using getPackageInfo(), which lead to
issues in other places, for example the dependency ordering
and resolving class PackageCollection.

This change streamlines the ComposerPackageManager class
to 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

…Manager`

The `ComposerPackageManager` has been introduced to streamline
the 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`:

* typo3/sysext/backend
* backend

For `$testExtensionsToLoad`:

* typo3conf/ext/my_ext_key
* my_ext_key

With `typo3/cms-composer-installers` version 4.0RC1 and
5 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` has
been 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 code
places and including not obvious side effects and lookup
issues. `basename()` was also used on valid composer package
names 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 name
resolved and retrieved the TYPO3 system extension package
`typo3/cms-fluid` using `getPackageInfo()`, which lead to
issues in other places, for example the dependency ordering
and resolving class `PackageCollection`.

This change streamlines the `ComposerPackageManager` class
to 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
@sbuerk sbuerk merged commit 1530ae5 into main Nov 28, 2024
6 checks passed
@sbuerk sbuerk deleted the main-stefan-2 branch November 28, 2024 18:45
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

typo3fluid/fluid dependency picked up as sysext fluid
2 participants