Open kazajhodo opened 3 years ago
This topic has been brought up a few times before (#145, #170, and feedback to #189) but the plugin is behaving as intended.
From my brief experience working on the Merge Plugin and reading Composer's source code, this is a complex issue that would require a significant redesign of how dependencies are tracked, merged, and installed.
I've looked into it a little, while I was adding support for Composer 2, and the only solution I can think of is integrating Composer's "Allow-List" concept:
This could maybe be resolved using
setUpdateAllowList()
withsetAllowListTransitiveDependencies()
in Composer 1 andsetUpdateAllowTransitiveDependencies()
in Composer 2.
— See discussion in #189
This is tracking the problem where a lock file might lock at 1.1.2 but composer install
will end up with the latest 1.1.5?
making a simplified test case for that comment I can't recreate what I saw upgrading a larger ~problem~ project so... ignore for now. I'll follow up with a better issue.
Run composer update --lock
instead.
The plugin is forcing a 'composer update' run, in order to match up the json/lock files.
I realize why, but in very low situations should anyone want to ever actually run an update on their build. This is way too opinionated. Its forcing me to maintain a fork- I wouldn't be surprised if most of the forks were doing similar things.
As the comment mentions- it should be a message vs an action.
We can very easily run 'composer u nothing', or some of the other variants that update the lockfile only.
I'm not sure if this will work, but I see within MergePlugin.php that you are setting options on the $installer object- such as the --prefer-source option with $installer->setPreferSource(). The update command has a '--lock' option, which is likely also available on the $installer... maybe setLock()? I haven't looked.
I'm betting you could set that before you trigger the $installer->setUpdate(true);, which would alleviate the issue.