CLI command for adding patches
In the same way that Composer includes a "require" command, so that you can run composer require cweagans/composer-patches instead of editing composer.json to insert the dependency, it would be really nice if composer-patches provided a way to patch packages from the command line.
I could see this either taking the form of a patch command, or an additional patch parameter to the require command (if Composer lets you modify built-in commands... not sure).
For anyone looking for a workaround, I can't really find one. I was hoping composer config would work but it doesn't allow setting an array below three levels deep. So you can't add a new patch without deleting all of the existing ones.
I would really use this as well. And thanks @danepowell for saying that the workaround I had in mind doesn't work either. Have you found anything besides loading combo.json and writing it back to disk? Ping @grasmash as well.
This package could provide a static method that would read the composer.json file, modify, and write it to disk. That method can then be placed in a script in your composer.json:
"scripts": {
"add-patch": "Cweagens\\ComposerPatches\\Plugin::add-patch"
}
Allowing you to call composer add-patch [patch.patch].
Plugins can provide commands, I think. No need to define a separate script in your composer.json.
Yes: https://getcomposer.org/doc/articles/plugins.md#command-provider
And I see references to command-y things here... https://github.com/cweagans/composer-patches/blob/master/src/Patches.php#L354
But I definitely don't understand how I'm meant to use it/them!
The steps are basically as follows:
- Implement
Composer\Plugin\Capability\CommandProviderincweagans\Composer\Patches- this should return an array of Command objects. - Create a new class that extends
Composer\Command\BaseCommand.configure()should set the name of the command (i.e.patch-addor whatever - see example you linked for the exact syntax) andexecute()should actually do the work of loading composer.json (or the configured patches file) and adding the patch.
If you start working on this and get stuck, push your code somewhere and let me know. Happy to help as needed.
I think this is a very useful case of a generic CLI json modifier. I remember there was a drupal-console generic yaml modifyer.
Would really love to see both (the generic one and the patches one, maybe just depending).
https://stedolan.github.io/jq/ https://github.com/grasmash/yaml-cli
This is on the roadmap for 2.0.0 (see #93)
Nice to see, that the CLI is on the Roadmap for 2.x.
Recently I started an initial composer patches CLI plugin for the 1.x branch at https://github.com/szeidler/composer-patches-cli , to test a bit, what is possible and what not.
We used it for adding the recent Drupalgeddon security patches in an automated way.
I saw that. :) I'll probably end up using a fair amount of your code -- there's a lot of good stuff there.
Note: The mentioned szeidler/composer-patches-cli only works for adding patches via extra/patches-file. It does not work for patches added via extra/patches.
Would it be possible, as part of this, to allow for optional metadata to be stored with a patch. If we could work out how to allow for optional extra metadata with a patch, that'd be great. Currently we only have a single key-value for a each patch.
If the patch storage JSON structure could accommodate more, optionally, we do...
...Thinking like:
- patch-type (ie. github, drupal, bitbucket, gist, file) for use by a plugin
- patch-issue-id (ie. 2493183, ABC-123)
- patch-issue-uri (ie. https://www.drupal.org/node/2493183, https://github.com/vendor/repo/issues/81 )
This would be helpful so that add-ons / plug-ins could be written to support management of patches by calling issue queue apis, to check on the status of an issue associated with a patch.
Would be happy to track this separately as a Nice to Have, or somewhere else on the roadmap.
@christopher-hopper, @cweagans stated above that he was planning to use a lot of @szeidler's code from szeidler/composer-patches-cli. This repository includes the functionality that you are asking for.
@christopher-hopper Please open an issue for that. I'm not opposed to adding additional optional metadata fields for Patch objects in the 2.x releases.
I've made a note to handle this in main.
So, is this feature implemented in the core functionality, or not yet? I see that it is closed as completed on Feb 8, 2023, but I can't find any documentation about how to use the CLI.
I haven't added it yet. Feel free!