Recipe Composer plugin: support wikimedia/composer-merge-plugin

Ugh... the merge plugin is super complex. I think we should do the quick thing first and add a conflict to the composer.json. That will stop existing projects from breaking if they require this. Then we can open up an issue to try to deal with the root cause. I do not think it will be pleasant because the merge plugin is really icky. Why are you using it? Hopefully it is just a legacy of what Drupal used to do.

I ran into the same issue yesterday with a Recipe that depends on BEF. BEF includes a composer.libraries.json file in its package, which you can see here:
https://git.drupalcode.org/project/better_exposed_filters/-/blob/7.0.x/c...

I agree that Wikimedia’s setup is quite complex. In our monorepo, we also treat it as a necessary evil rather than something to optimize around, so I don’t think compatibility with it should be a primary concern.

To avoid this issue in our setup, we updated our include rule from the broad composer.*.json to something more specific like composer.dev.json, which prevents BEF’s composer.libraries.json from being picked up unintentionally.

That said, I’d recommend opening a follow-up issue to improve the error reporting in the assertion logic, so it provides clearer feedback when Composer’s actual state doesn’t match the expected configuration.

The follow up ✨ Improve error reporting when Composer state missmatch Active .

Hi,

Thanks for the quick feedbacks.

Webform also provides a composer.libraries.json: https://git.drupalcode.org/project/webform/-/blob/6.3.x/composer.librari... which I suggested in #2974114: Composer merge plugin support → long time ago to ease updates.

So for projects providing additional libraries, it can be/is useful.

the merge plugin is super complex

I agree that it can have side effects depending on your configuration and what is merged.

Why are you using it? Hopefully it is just a legacy of what Drupal used to do.

Unfortunately no ^^. It is by default in my project stack: https://gitlab.com/florenttorregrosa-drupal/docker-drupal-project/-/blob...

- to merge custom modules/profiles/themes composer.json: 1) in case I want to split dependencies into the module using it, mainly for documentation purpose in case a custom modules is extracted from the project. 2) when developing install profiles like https://www.drupal.org/project/sobki_profile_bootstrap → .
- and like mentioned above for modules with external libraries

For the record, I generally land closer to @alexpott's position here. The merge plugin is ridiculously complicated and adds enormous complexity, and is likely to significantly increase the number of bugs and edge cases. I'd prefer to conflict with it, at least initially, and then later we can figure out how and if to support it.

The composer-merge plugin is a necessary evil, mainly because Drupal does not have a clean way of managing frontend dependencies that a contrib module/theme may require. The plugin makes it easier to manage these depenencies of dependencies that may have their own "repositories" that need to be defined.

Some examples:

• Recomended use by the webform module → ( community docs saying the same thing →
• Use by Better Exposed Filters ✨ Add composer.libraries.json Active
• Use by Timepicker module
• Use by the Klaro consent management module → :

I find composer.libraries files to be the most reliable and best DX.

Sometimes asset packagist is out of date, or has weird names/differences between npm and bower.

I just ran into an issue with fontawesome. While waiting for a patch to composer.libraries.json to get accepted, I can just copy the repository definition into my root composer.json.