Investigation for provided change / notes¶
Using `self.version` for the replaces is not usable for us. The answer from `Ocramius ` in the linked issue is a generic answer, and valid for a monorepo metapackage + splitt package style, for example what symfony provides. The TYPO3 has not such a approach.
This change would render the `replaces` use-less from the original attempt. The attempt is, to silently replaces outdated/removed split packages with another image so an update simply works even if the old package is contained in the project/extension composer.json directly.
For example, having a (simplified)
{
"require": {
"typo3/cms-core": "^10.4",
"typo3/cms-about": "^10.4"
}
}
and a upgrade will be done using:
composer require "typo3/cms-core":"^13"
the death stare would remove the dedicated package due to the replace. With `self.version` it will complain with following errors:
Loading composer repositories with package information
Updating dependencies
Your requirements could not be resolved to an installable set of packages.
Problem 1
- typo3/cms-about v10.4.0 requires typo3/cms-core 10.4.0 -> satisfiable by typo3/cms-core[v10.4.0] from composer repo (https://repo.packagist.org) but typo3/cms-core[13.1.x-dev] from path repo (../../typo3/sysext/*) has higher repository priority. The packages from the higher priority repository do not match your constraint and are therefore not installable. That repository is canonical so the lower priority repo's packages are not installable. See https://getcomposer.org/repoprio for details and assistance.
- typo3/cms-about v10.4.1 requires typo3/cms-core 10.4.1 -> satisfiable by typo3/cms-core[v10.4.1] from composer repo (https://repo.packagist.org) but typo3/cms-core[13.1.x-dev] from path repo (../../typo3/sysext/*) has higher repository priority. The packages from the higher priority repository do not match your constraint and are therefore not installable. That repository is canonical so the lower priority repo's packages are not installable. See https://getcomposer.org/repoprio for details and assistance.
.... +xxx similar errors
Even if following is used:
composer require "typo3/cms-core":"^13" "typo3/cms-about":"^13"
the current state would silently replace it where as the new thing would badly fail with a long list of errors. Sadly, most developers out there never really learned composer correctly and is not firm would really be confused and comming into cms channel asking for support. Just documenting it would not really help as they would not search for such things.
The pinpoint here is, that there will not be a package version for the removed version in packagist meta-data matching the same version like the other packages.
failing one and drastically making the `User eXperience` a multidude worser.
Note: this can be simply tested with following steps (with and without this change:
cd Build/composer/ && \
rm -rf public vendor composer.json composer.lock && \
cp composer.dist.json composer.json && \
composer require --no-update --no-install \
"typo3/cms-about":"^10.4" && \
composer install && echo '>> success - yeah !' || echo '>> failed - bad'
Further handling¶
This requires first a deep discussion into which user experience we want to
end finally - and take than the appropiated actions.
Updated by 
Updated by 
Updated by 
Updated by 
Updated by Anonymous