• Given I have Drupal 9 composer installation with composer-patches plugin
  • and given a contrib module with a stable v8 release, but no v9 release (not even dev branch)
  • and given that contrib module has a working v9 patch in the issue queue

is there any method to install that module + patch in composer? Even if I manually add both, the package and patch, to my composer.json, I still can't require or update this module with composer due conflicting versions. I really want to avoid duplicating /contrib code into my project's /custom codebase. My current workaround is:

  • forking that module to my own, private git repo
  • applying patch there
  • creating a new composer.json in my private git, and changing the package vendor to my custom_private_vendor
  • adding my private git as VCS repo in the D9 project's composer.json
  • and then composer require custom_private_vendor/contrib_module

This fulfills my goal of not duplicating the contrib module in my project's custom codebase, but every time I do this I feel the urge to wash my dirty hands.

Is there something more elegant like composer require drupal/contrib_module --apply-patch-first or can I somehow target drupal.org's git with a specific patch included?

有帮助吗?

解决方案

You've got the right idea but you don't need to fork Drupal's repository. You can set up composer to read Drupal's git repo instead of using packagist for the naughty modules like this:

    {
        "type": "package",
        "package": {
            "name": "drupal_git/cache_control_override",
            "type": "drupal-module",
            "version": "1.0.0",
            "source": {
                "type": "git",
                "url": "https://git.drupalcode.org/project/cache_control_override.git",
                "reference": "8db91684a427366d8f9c51f60cbac10c2d586d95"
            }
        }
    },

Note the 'reference' is a commit hash, though it looks like you can also use tags.

And then patch as normal using composer:

"drupal_git/cache_control_override": {
    "Drupal 9 Compatibility (3132036)": "https://www.drupal.org/files/issues/2020-04-29/Drupal-9-readiness-3132036-2.patch"
},

(Shamelessly stolen from @acbramley on Drupal Slack because wider dissemination of this knowledge is worthwhile)

其他提示

For a wider explanation of why Darvanen's answer is necessary, see https://www.computerminds.co.uk/articles/apply-drupal-9-compatibility-patches-composer (disclaimer: I wrote this). But do note that using a different vendor namespace (like drupal_git) shouldn't be necessary if the section is added to your composer.json file's 'repositories' above the one for packages.drupal.org .

Ultimately, composer processes the dependency & compatibility metadata for packages, and so decides to reject the package - before composer gives the cweagans/composer-patches plugin chance to patch it. This method overrides the metadata so the package isn't rejected before patching.

许可以下: CC-BY-SA归因
scroll top