Write copy of a patch to a project directory for code review

[donquixote]

Verification

• I have updated Composer to the most recent stable release (composer self-update)
• I have updated Composer Patches to the most recent stable release (composer update cweagans/composer-patches)
• I am using one of the supported PHP versions (8.0+)
• I have searched existing issues and discussions for my idea.
  (maybe different search terms would lead to a result - I can't say)

Is your feature request related to a problem?

For patches from root composer.json:

• When working with remote patches, there is a risk that the same patch url might return something different in the future, possibly malicious.
• When working with local patches, developers can easily lose track of where the patch was downloaded from. On the other hand, local patch files can be verified in a code review.

For patches from dependencies:

• A project developer has no control over patches from dependencies.
• A patch url from a dependency could one day return something different, possibly malicious. This is the same problem as above, just with even less control.
• On the other hand, if we disable patches from dependency and instead define them locally (currently not possible), then it will be really hard to keep track, and create the local patch files needed for specific dependencies.

Describe your proposed solution(s)

Create a mechanism that does both:

• The developer specifies a remote url to download the patch from. This can include patches from dependencies.
• The patch is downloaded into a local directory inside the project, managed by version control.
• The patch is applied. (TBD)
• The developer can review the changes in the patch files with e.g. git diff.

All steps of this mechanism have to be part of composer-install, because new versions of dependencies might bring new patches.

TBD: The developer might want to review the patch before it is applied. Not sure how this can be done if it all has to be part of composer-install.

Describe alternatives

The patch content and/or a checksum could be written into composer.lock.

The problem with checksum is that it would be very convenient for developers to ignore a change and to think it is all good.

Additional context

No response

[github-actions]

👋 Thanks for the idea! Please remember that this is an open source project - feature requests may or may not be implemented, and if they are, the timeline is unknown. If you need a guaranteed implementation or timeline, sponsorships are welcome!

[cweagans]

This is already covered in the 2.0.0 beta. Patch checksums are stored in a patches lock file (separate from composer.lock because of limitations in composer 2). Please update to that beta release and let me know what you think!

[cweagans]

Closing for now, but let me know if you need something more than what 2.0.0-beta1 provides.

[donquixote]

Patch checksums are stored in a patches lock file (separate from composer.lock because of limitations in composer 2).

Checksums are an improvement.
But there is still the problem that reviewers would just overlook a checksum change, thinking it is "probably just a reroll".
If the entire patch is downloaded and tracked in git, then the actual functional changes will be much more visible in a review.

Please update to that beta release and let me know what you think!

Hi
I tried to test the v2 on the project I was working on.
But the 3rd party packages that introduce patches still required the v1 of composer-patches. So I stopped it for now.
I even tried "2.something as 1.something", but this ran into an incompatibility somewhere.
I should give it another go.

[donquixote]

This is already covered in the 2.0.0 beta.

Is there an existing issue, change record or PR to look at?

[donquixote]

I see:

• Patches from drupal.org merge request URLs are dangerous? #347:
• Add support for patch checksums #388:
• Validate Patch Checksum #163:
• Add checksum to patch definition #19:
• https://github.com/cweagans/composer-patches/pull/447/files#diff-0ddfea73aecdd132226d14a339e4a890f726efaa8511468c0dba33dc22de7325R11