Problem/Motivation

If you are using wikimedia/composer-merge-plugin on a project, then the new Recipe unpack Composer plugin will not work because in RootComposer.php

In RootComposer.php line 142:

  [AssertionError (1)]
  Composer root package and composer.json match
  private static function checkRootPackage(string $composer_content, RootPackageInterface $root_package): bool {
    $composer = JsonFile::parseJson($composer_content);
    return empty(array_diff_key($root_package->getRequires(), $composer['require'] ?? [])) && empty(array_diff_key($root_package->getDevRequires(), $composer['require-dev'] ?? []));
  }

In $composer the result of the merge from wikimedia/composer-merge-plugin are present.

Steps to reproduce

- Use wikimedia/composer-merge-plugin
- Have some composer.json with require and/or required-dev merged.

Proposed resolution

- Remove this check?
- Execute the unpack plugin before Composer merge plugin?

Remaining tasks

Determine solution.

Release notes snippet

Issue fork drupal-3525727

Command icon Show commands

Start within a Git clone of the project using the version control instructions.

Or, if you do not have SSH keys set up on git.drupalcode.org:

Comments

grimreaper created an issue. See original summary.

alexpott’s picture

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.

mxr576’s picture

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.

mxr576’s picture

grimreaper’s picture

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

thejimbirch’s picture

Issue tags: +Recipes initiative
phenaproxima’s picture

For the record, I generally land closer to @alexpott's position here. The merge plugin is ridiculously complicated and supporting it is likely to significantly increase the number of bugs and edge cases we need to deal with. I fear that will make the unpack plugin less usable, less focused, and less reliable.

I'd prefer to conflict with it, at least initially, and then later we can figure out how and if to support it.

chrissnyder’s picture

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:

mortona2k’s picture

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.

b_sharpe made their first commit to this issue’s fork.

b_sharpe changed the visibility of the branch 3525727-conflict-with-unpack to hidden.

b_sharpe’s picture

Status: Active » Needs review

Could we not change the check to only care that the recipe's requirements are now in root? isn't that really what we want to assert here anyhow? MR created for review

needs-review-queue-bot’s picture

Status: Needs review » Needs work
StatusFileSize
new91 bytes

The Needs Review Queue Bot tested this issue. It no longer applies to Drupal core. Therefore, this issue status is now "Needs work".

This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.

Consult the Drupal Contributor Guide to find step-by-step guides for working with issues.

nod_’s picture

Status: Needs work » Needs review
bsnodgrass’s picture

A number of folks discussed this on Tuesday, 21 Oct in this thread https://drupal.slack.com/archives/C2THUBAVA/p1761067508458619 during the recipes bi-weekly meeting.

I didn't see a note about it here on the issue

norman.lol’s picture

StatusFileSize
new1.06 KB

Adding a static patch here that can be used directly with the drupal/core-recipe-unpack dependency in the root composer.json to avoid error:

No available patcher was able to apply patch https://git.drupalcode.org/pro
ject/drupal/-/merge_requests/13442.diff to drupal/core-recipe-unpack

        "patches": {
            "drupal/core-recipe-unpack": {
                "[https://drupal.org/i/3525727] - Recipe Composer plugin: support wikimedia/composer-merge-plugin": "https://www.drupal.org/files/issues/2025-10-27/3525727-18.patch"
            },
alexpott’s picture

Love the test coverage this is looking really good. Nice work.

norman.lol’s picture

How will this actually land in the actual plugin? https://github.com/drupal/core-recipe-unpack

Shouldn't the MR here only contain test coverage? And then there be another MR directly to https://github.com/drupal/core-recipe-unpack?

How does this work?

mxr576’s picture

Status: Needs review » Reviewed & tested by the community

How will this actually land in the actual plugin? https://github.com/drupal/core-recipe-unpack

AFAIK via git split from Drupal core, so there is no need to touch that project directly.

Changes and test coverage looks good to me, I am really glad that this problem could be fixed with such a simple change!

alexpott’s picture

Version: 11.x-dev » 11.2.x-dev
Category: Feature request » Bug report
Status: Reviewed & tested by the community » Fixed

Backported to 11.2.x as a bug fix.

Committed and pushed 276fb1ab62a to 11.x and 726d7ea0461 to 11.3.x and 193bcef1018 to 11.2.x. Thanks!

Now that this issue is closed, review the contribution record.

As a contributor, attribute any organization that helped you, or if you volunteered your own time.

Maintainers, credit people who helped resolve this issue.

  • alexpott committed 193bcef1 on 11.2.x
    Issue #3525727 by alexpott, mxr576, grimreaper, phenaproxima, b_sharpe:...

  • alexpott committed 726d7ea0 on 11.3.x
    Issue #3525727 by alexpott, mxr576, grimreaper, phenaproxima, b_sharpe:...

  • alexpott committed 276fb1ab on 11.x
    Issue #3525727 by alexpott, mxr576, grimreaper, phenaproxima, b_sharpe:...

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.