Open schmunk42 opened 1 year ago
I found this issue occurs when the main composer.json is merging another composer.json with the same package requirement. What happens is the merged package takes priority and supersedes the main composer.lock version. Causing an update on composer install
for the identical packages. For example:
Main composer.json:
{
"require": {
"example/package": "1.4"
},
"extra": {
"merge-plugin": {
"include": ["path/to/merged/composer.json"],
}
}
}
Merged composer.json:
{
"require": {
"example/package": "^1.5"
}
}
The workaround is to set extra.merge-plugin.ignore-duplicates
to true
in the main composer.json. This ensures the main composer.lock version is always used. I have not tested how well this works with version based dependency resolution. It's probably up to project maintainers to be sure their main composer.json constraints are compatible.
https://github.com/wikimedia/composer-merge-plugin#ignore-duplicates
The workaround is to set extra.merge-plugin.ignore-duplicates to true in the main composer.json.
We have that in almost all projects, but I haven't found it to be a cause for this specific issue.
I wouldn't be surprised if there are multiple ways to create the issue. However, the workaround did indeed fix the issue in the described use case. You might want to review the lock files of your main and merged composer.json files.
This would be my take for:
Alternative for:
Actually the callback
onPostInstallOrUpdate
should also be renamed into something more descriptive, but anyways.As stated in https://github.com/wikimedia/composer-merge-plugin/issues/252#issuecomment-1378669751 there's no need to run an update or any special processing when using
install
.I've tested this in several use-cases: first install, regular install with and without
.lock
file. And it looks good to me so far. Especially the edge-caseinstall
without.lock
file is handled correctly -> it is treated asupdate
.