0

I maintain a project in 2.3.5-p2 and for security reasons I want to use much more modern php version. An issue with that are that dependencies may use older signatures for the php core functions.

What is the reccomended approach to tackle it?

  • Have a folder patches and place modified dependency files (originally from vendor) where will be copied back to ./vendor folder after composer install using at installer events.
  • Fork any breaking dependency patch it and replace in using composer replace: https://stackoverflow.com/a/18905069/4706711.
  • commint ./vendor into git and never do composer install. (Hard to swallow pill)

Upgrade is the best option but time consuming as well and my boss cannot afford the time.

Improve this question

1 Answer 1

Reset to default
0

I believe the first one is the better and recommended approach to handle this.

Have a folder patches and place modified dependency files (originally from the vendor) which will be copied back to the ./vendor folder after the composer installs using installer events.

It gives you much more control over patches that are being applied and does not affect your usual composer installation process. You can use composer installer events to achieve this however there are some other libraries available that help you achieve the same in a more efficient way. The following are some of the libraries that I have used so far, you can find their documentation in the link:

You can also refer Apply Patches | Adobe Commerce.

As for second approach which is

Fork any breaking dependency patch it and replace in using composer replace: https://stackoverflow.com/a/18905069/4706711.

We can fork the breaking dependencies, create a patch for it followed by adding it in the "patches" folder, and let it be applied via composer using the first approach instead of using "replace". "replace" will require us to replace the whole package even when we have only patched only a single file.

Improve this answer
4
  • The issue is that if something breaks upon patch management my coleaguwes will spend much more time to debug i. Instead If I have a folder patches and use a typical copy-paste (via scripts and event hooks) will be much more preferable. I mean it gets no simpler by an automated copy-pasta.
    – Dimitrios Desyllas
    Sep 25 at 12:15
  • Also a good idea is somehow to have the patches pre-applied into the file ./patches folder bot better auditing. The commit the patched file ans upon CI/CD the composer will do the typical copy-paste.
    – Dimitrios Desyllas
    Sep 25 at 12:18
  • If you are keeping the patched file in the folder then typical copy-paste makes more sense but you will also have to mention the destination where the patched file is expected to be copied along with the patch's path every time you add a new patch. It seems too much of a work just to apply a patch.
    – Rishabh Dwivedi
    Sep 25 at 13:24
  • I still think keeping only the .patch file(not the patched file) in the patch folder and applying it during the composer install is a better way to do it. It will give you more control over the patches you are applying and does not require you to add any script in CI/CD pipeline or server. Also, access to CI/CD pipelines or servers is usually limited to only a few people on the team. If we still want to add script then rather than copying the file we can use git to apply patch after composer install which will remove the dependency from the composer.
    – Rishabh Dwivedi
    Sep 25 at 13:25

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.