Composer patches only respects composer.json

[pingers]

When running composer install, I expect the composer.lock file to be respected, but instead, the patches defined in composer.json are always used. This isn't critical by any stretch, but it's not consistent with the way composer works.

Proposal:

• Respect composer.json during composer update
• Respect composer.lock during composer install

[cweagans]

👍 Yeah, I agree. This makes a lot of sense. I don't have a lot of time to work on this right now, but if you want to submit a PR, I'd be more than happy to merge it. It should be pretty straightforward.

[cspitzlay]

I think this behaviour is also at the bottom of an issue we are having.
Our setup uses both cweagans/composer-patches and wikimedia/composer-merge-plugin.
We have several composer.json files in subdirectories that are merged together by the merge plugin. These composer.jsons may contain patches.

We're seeing that patches are applied on composer update but not on composer install.
I guess the problem is that the logic to merge the composer.jsons does not run
on composer install, hence no patches from the subdirs are found.

Our current workaround is to move all the patches to the toplevel composer.json.
This seems to be the only file the patches plugin looks at for gathering patches.
This workaround is a bit ugly as it breaks the modularity we tried to achieve.

IIUC a composer.lock file is supposed to define the whole installation including versions (and by extension patches) and thus should be self-contained.
I think that fixing this issue here would be a step in that direction (and at the same time fix the incompatiblity with the merge plugin, too).
This makes me think that the patches plugin is the right place to fix this (instead of making the merge logic run on composer install which may be another way to solve this).

[whittaker007]

Sorry to reply on a closed issue, but I'm having the same issue as @cspitzlay above - that is we are using wikimedia/composer-merge-plugin so we can have a standard composer.json for certain kinds of project, and an instance-specific composer.local.json.

If we add patches to requirements in the composer.local.json they install fine, but building a new site instance using composer install with the current composer.lock (which does appear to contain references to the patches) the patches are not installed.

Manually running "composer update" for the requirement does not apply the patches on the new instance. The only workaround I've discovered to work reliably is to delete the destination folder which contains the requirement being patched and run "composer install" again.

I notice that this issue has been closed, but this particular issue doesn't seem to be resolved. Is the fix in the coming 2.x branch?

[cweagans]

This issue is still open :)

[bkosborne]

I think this is critical for anyone using the composer merge plugin. What's really strange is we can get it working correctly only if we manually remove the "patches_applied" section from the composer.lock file for each package that was patched from one of the merged composer.json files. If we do that, then when composer install is run, it will actually re-examine the composer.json file(s) for patches and include them.

So our current workaround is very hacky - we have to remember to manually remove the references made in composer.lock when we include new patches.

[eelkeblok]

Although this makes a lot of sense, what would be the workflow for just applying a patch to the current version of a dependency, without actually updating the "base" version of the dependency? Currently, that just requires adding the patch to composer.json and rerunning composer install.

I actually came here looking for an issue about composer.lock not being updated when you run composer install with a new patch, and having to run composer update --lock to get it to be added correctly.

[cweagans]

It's not composer.lock because that isn't super feasible, but main has a lock file now.