Edited composer.json, "now what"?

[webchick]

The docs are good about explaining the difference nuances of how to edit your composer.json to add a patch.

They are missing a "now what?" composer update? composer install? composer shenanigans? ;) A little help would go a long way, especially for those new to Drupal 8/9 and Composer.

[cweagans]

Usually, composer update your/package (for whatever thing you patched). Usually, composer install your/package will cause it to be removed and patched as well, but there's some funky behavior in some cases that I haven't narrowed down just yet. update is the most reliable path afaik!

I'll make a note to document this at some point. Thanks for pointing out that this is missing!

[lpeabody]

Throwing my hat in the right for composer update --lock. I've generally found that command to be perfectly sufficient, and it doesn't update any packages to new versions when I'm only concerned about applying a patch to my current version.

I don't like the idea of updating the version of the package at the same time as applying the patch because I want to test only the behavioral changes introduced by that patch. If the patch is meant to be applied against a specific version of something, then yes I will try to update my package to that version because that's what version other people are presumably working with as they modify/update the patch over time in the issue queue.

[paul-m]

General panic button:

rm -rf vendor
composer install

This handles the case where Composer gets mixed up about whether to do the patches plugin or the drupal-composer/preserve-paths first.

[webchick]

Three different comments with three different recommendations. ;) This is why some "official" guidance would be helpful, IMO.

(Thanks for the input though, that's helpful to have different things to try!)

[eiriksm]

Here is a fourth: i always run composer update nothing after adding a patch

[mstrelan]

FWIW it might nice to have a composer add-patch or similar command that modified the composer.json file AND ran the appropriate command.

[matzeeable]

I solved this with a workaround. Just put this in your ~/.bashrc which creates a function composer-patch:

composer-patch() { DELETE_FROM_VENDOR=$(composer config extra.patches | jq -r 'keys | join(" ") ') cd $(composer config vendor-dir) && rm -rf $DELETE_FROM_VENDOR && cd - > /dev/null && composer install; }

Navigate to your composer project and simply do:

composer-patch

It automatically removes all folders which needs to be patched from the vendor folder and reinstalls them with patches.

[cweiske]

composer update nothing is the same as composer update --lock, but the latter should be used as it is officially supported: https://github.com/composer/getcomposer.org/issues/92#issuecomment-174937826

[joshuami]

Could I recommend merging the related PR to update the documentation? I just ran across this discussion after a bit of friendly intra-team debate. It's always fun to learn you've been applying patches wrong for years. 😄

I'm having my teams standardized on composer update --lock as there are times when composer update repo/package might introduce a change that was incompatible with the patch and there may be arguments to pinning to a previous version if a patch has not yet been rerolled.

[cweagans]

main now has explicit commands for generating a patches.lock and for re-patching dependencies. I'll include that in the docs (Coming Soon :tm:)

[cweagans]

I documented some recommended workflows here and lots of other things on that same site. Feedback welcome!