Is the composer merge plugin needed/necessary?

[ericp-mrel]

Hi all, I was just wondering what the purpose of the composer merge plugin is for wikimedia/composer-merge-plugin? Is it actually necessary when all of your dependencies are already included through your root composer.json file.

Let's say you install a plugin using composer and that plugin has its own set of composer dependencies, wouldn't those already be included by the nature of being included via the root composer.json file rendering the composer merge plugin kind of useless/unnecessary?

Just trying to figure out if it is even necessary or if I could even just remove it since it can cause issues when trying to update plugins sometimes to newer versions and conflicts arise as a result.

[bennothommo]

@ericp-mrel It will be needed for people creating custom plugins and implementing their own composer.json file in the plugin during development, since the vendor files won't be available until they run composer update, in which at that point the merge plugin will do its magic.

If there's conflicts arising, that would probably indicate a problem with the dependencies of the plugin, and we'd likely hit the same conflict when trying to package the vendor files for the plugin to deliver through the marketplace. Do you have any examples of where these conflicts are arising?

[ericp-mrel]

Based on my experience with writing my own private plugins which are managed through a private satis repo of mine, all of the composer dependencies my plugins have listed in their composer.json files get included just fine without the composer merge plugin being installed. In fact, I've even removed it and haven't noticed any issues with dependencies not getting included that my plugins depend on. (which is why I'm asking if it is even needed as long as the winter cms plugin is required through the root composer.json file). And since the marketplace builds the vendor folder for you as well, there isn't a composer.json file listed with the plugin when installed that way so the composer merge plugin doesn't serve any purpose there either.

And I mostly see conflicts when I have an old version of my plugin installed which has an older version of a dependency and the updated plugin has a newer version constraint in its composer.json file for its dependency and so with the composer merge plugin, since it's looking at the composer.json file of the older version of the plugin that is currently installed it gets confused because now there are two composer.json files that are trying to be merged (the new one pulled from the currently being updated one from packagist or wherever and the one from the locally installed plugin folder).

Hope this makes sense, and just wondering if you would consider removing the composer merge plugin since to me it seems useless and isn't serving any purpose based on the fact that plugins installed through composer have their dependencies included by default anyways without this plugin and the only time it wouldn't is if you manually downloaded a plugin zip file from github and placed it in the plugins folder, but I feel that is a pretty rare situation and would be best to just include the plugin using composer anyways.

[LukeTowers]

@ericp-mrel The main use case is when you're developing a plugin with dependencies for the project but the plugin does not exist in a separate repository. This is especially helpful when building project-specific plugins that have dependencies that need to be managed, but don't justify having their own repository and release process because they're only ever going to be used in the one project.

By all means if it serves no purpose for your specific workflow, feel free to remove it entirely, but it does still provide value to other people.

[ericp-mrel]

Ok, Thanks!

I was just wondering what use-case it was serving so thanks for explaining one situation where it would be useful and if there would be any hidden gotchas I wasn't aware of (yet) by removing it.

Although for me when I have site specific plugins, I usually just add the dependencies to the root composer.json just to make things easier, but that's just me.

[LukeTowers]

Although for me when I have site specific plugins, I usually just add the dependencies to the root composer.json just to make things easier, but that's just me.

While that technically works, it's more correct to add it to the plugin itself since the code that actually utilizes those dependencies is within the plugin, and it makes it a bit easier to maintain long term, but yeah, whatever works best for your workflow.

[ericp-mrel]

The main use case is when you're developing a plugin with dependencies for the project but the plugin does not exist in a separate repository. This is especially helpful when building project-specific plugins that have dependencies that need to be managed, but don't justify having their own repository and release process because they're only ever going to be used in the one project.

By all means if it serves no purpose for your specific workflow, feel free to remove it entirely, but it does still provide value to other people.