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
| Comment | File | Size | Author |
|---|---|---|---|
| #18 | 3525727-18.patch | 1.06 KB | norman.lol |
Issue fork drupal-3525727
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
Comment #2
alexpottUgh... 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.
Comment #3
mxr576I 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.
Comment #4
mxr576The follow up #3525769: Improve error reporting when Composer state mismatches.
Comment #5
grimreaperHi,
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.
I agree that it can have side effects depending on your configuration and what is merged.
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
Comment #6
thejimbirch commentedComment #7
phenaproximaFor 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.
Comment #9
chrissnyderThe 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:
Comment #10
mortona2k commentedI 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.
Comment #14
b_sharpe commentedCould 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
Comment #15
needs-review-queue-bot commentedThe 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.
Comment #16
nod_Comment #17
bsnodgrass commentedA 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
Comment #18
norman.lolAdding a static patch here that can be used directly with the
drupal/core-recipe-unpackdependency in the root composer.json to avoid error:Comment #19
alexpottLove the test coverage this is looking really good. Nice work.
Comment #20
norman.lolHow 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?
Comment #21
mxr576AFAIK 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!
Comment #22
alexpottBackported 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!