Add varbase:composer:cleanup:patches drush command to clean up composer.json from any merge request patches

1. Let us use try catch

try {

}
catch (\Exception $e) {

}

2. Let use the \Drupal::logger('Varbase') to log the fixes
3. Let use drush logger for std output from drush
3. Maybe check if the folder patches is in the system ( if the chmod, chown, was not right )
4. Give a warning if the Merge request was added twice

• maybe it was in the composer.json file before
• then a run for ./bin/drush varbase:composer-clean-up or lando drush varbase:composer-clean-up fixed it
• And then another patch for the same project + the same MR was added again in some way

5. Maybe more scenarios.

Maybe we could add a flag or other command to only check if the root composer.json has "/-/merge_requests/"

Thank you, for the smart idea and implementation for it!
On the way for Better to ensure that our used patches are protected from any change.

Reviewed the code and merged
Optimizing the idea to follow with
Storage of Local Patches Branch
Examples of Names for Local Patch files

1. Grep on "/-/merge_requests" not only "merge_requests", as it may be in the file name of a a patch.
2. Add Project name, date , issue id and the MR number.

$project_name--$date--$issue_id--$mr_id.patch

• Adding the project name will ease browsing the patches folder.
• Having the date and time will timestampe the download time to track for history or further updates
• Having the issue id is important to ready more about the issue and track status update if more changes if it got committed into a release
• Having the MR id will help when having number of MRs in the same issue

Better to print out the list of clean patches ( better drush messaging )

✅ Released varbase-9.1.4 →

✅ Released varbase_core-9.1.35 →

Automatically closed - issue fixed for 2 weeks with no activity.

✅ Release varbase-10.0.0 →

✅ Released varbase-9.1.4 →