File based patches aren't resolved in dependencies

[deviantintegral]

I have a patch like the following:

            "drupal/core": {
                "Add option to disable settings.php hardening": "patches/drupal/1232572.43-sites-dir-hardening.patch"
            },

If that patches line is in an dependency, composer-patches looks for the file in the patches directory of the root package, instead of in the vendor directory of the package that adds the patch.

URL patches work around this nicely, but aren't great in scenarios where a patch is private or isn't accepted upstream.

[cweagans]

How critical is it that the patch is stored in vendor/drupal/core? I'm not sure why you'd want it there, because a composer update would nuke that entire directory. In addition, composer install might actually wipe it out too, since patched dependencies are deleted, re-installed, and repatched if the patch definition has changed.

[littlethoughts]

Hi @cweagans, I am also interested in using file based patches. Of course I wouldn't store them in a directory that contains generated files. The use case is that I have custom patches which I would like to apply, they aren't uploaded anywhere. Is this something that could be added? Edit: I didn't notice you can already do that, excuse me. Maybe add an example in the readme with a file based patch :)

[deviantintegral]

The patch itself is stored in the root of the project in a patches directory, not in vendor/....

[cweagans]

It took some time, but I see what you're saying now :)

If package A depends on package B, and package B defines a local path to a patch, the path should be relative to the installation root of package B. Makes sense, but might be somewhat problematic to implement.

[johnzzon]

This is a feature we'd benefit of in our latest project. We're building a profile for use in several of our sites, and this profile needs some core patches (which can be very use case specific changes, that we don't want to upload to an issue on drupal.org). We can host the patches ourselves in the meantime, but ideally we'd want to bundle them with the profile and not be dependent on external hosting.

[artemvd]

I have the same problem as @Johnzzon . I think the problem here is that the profile files are not there yet at the moment when its dependency is pulled. So it tries to patch the core with the files of profile, that were not yet downloaded, because not all the dependencies were resolved. Maybe if the patching is done after the package is cloned or downloaded, it would help. What do you think?

[Ambient-Impact]

Question: I've run into a very similar problem while using wikimedia/composer-merge-plugin, in that patching fails if I specify a relative patch path in a Drupal module I'm developing when that's merged into the root composer.json, likely because the merge plug-in doesn't know to resolve the path from being relative to the module to being relative to the root composer.json. Is there a way I can rewrite the paths somehow as a workaround?

[cweagans]

main no longer resolves patches from dependencies like 1.x does. Probably not going to fix this, sorry.

[Ambient-Impact]

Is there some alternative way to do something like this in 2.x? I ask because I've got multiple projects that use Drupal modules that patch another module they depend on because the other module(s)' maintainers are absent or barely around, and having this bundled up into our composer.json to automagically work is far simpler for our users than listing every patch they need to add to their root composer.json.

One example is the Config Enforce Devel module I help maintain. We have at least two patches that need to be applied to Config Devel for our module to function, but the maintainers of the latter seem to have disappeared and we need to have a working module in the meanwhile until that gets figured out. What happens if we still need to patch the module by the time 1.x is no longer compatible with the Composer version in use?