Forced Update

[kazajhodo]

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.

[mcaskill]

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() with setAllowListTransitiveDependencies() in Composer 1 and setUpdateAllowTransitiveDependencies() in Composer 2.

— See discussion in #189

[neclimdul]

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?

[neclimdul]

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.

[leymannx]

Run composer update --lock instead.