You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Regarding your first "To patch code in Composer modules" section:
When using composer-patches, I like to include composer-exit-on-patch-failure in the extra object, as it results in a non-zero exit code if a patch fails to apply. This is helpful when using a deployment tool like Capistrano, as deployment will fail and you can investigate the issue.
@cmtickle - How do you prevent Composer from outputting an error when you run composer update *** or composer install multiple times on a local development environment? Because once the patch is applied the first time, I expect it will output an error any subsequent times the patch command is run.
@cmtickle Got it. Considering that I run composer install and composer update **** dozens/hundreds of times across the course of an M2 project, I think that would get old after a while. :) But to each their own!
@erikhansen I guess once you're confident the patches apply you could just use the --no-scripts: argument for composer to avoid applying the patches again?
Remembering to reset the original unpatched version or using --no-scripts argument is not sustainable, not long term, not across multiple projects. The patch module should keep track of the patches applied and skip them. My 2c worth.
Cool tip on how to apply patches to
app/code
files (as an alternative to the approach I suggested here).Regarding your first "To patch code in Composer modules" section:
When using
composer-patches
, I like to includecomposer-exit-on-patch-failure
in theextra
object, as it results in a non-zero exit code if a patch fails to apply. This is helpful when using a deployment tool like Capistrano, as deployment will fail and you can investigate the issue.