Fix relative patch path for magento-ecg/coding-standard

[Copilot]

The ECG-72 patch was using a relative path (.vendor-patches/ECG-72.patch), which fails when openmage/magento-lts is installed as a dependency. Per composer-patches documentation, relative paths in dependencies resolve from the consumer's root, not the package root.

Changes

• composer.json: Changed ECG-72 patch to use absolute GitHub URL matching the pattern of other patches
• patches.lock.json: Updated URL and recalculated hash to reflect the change

All patches now use absolute URLs like:

"https://raw.githubusercontent.com/OpenMage/magento-lts/de83e28a673e3c1a249b51433abf6dc93e59063c/.vendor-patches/ECG-72.patch"

Warning

Firewall rules blocked me from connecting to one or more addresses (expand for details)

I tried to connect to the following addresses, but was blocked by firewall rules:

• https://api.github.com/repos/cweagans/composer-configurable-plugin/zipball/15433906511a108a1806710e988629fd24b89974
  • Triggering command: /usr/bin/php8.3 /usr/bin/php8.3 -n -c /tmp/2T31Pm /usr/bin/composer update --lock (http block)

If you need me to access, download, or install something from one of these locations, you can either:

• Configure Actions setup steps to set up my environment, which run before the firewall is enabled
• Add the appropriate URLs or hosts to the custom allowlist in this repository's Copilot coding agent settings (admins only)

Original prompt

---

This section details on the original issue you should resolve

<issue_title>[BUG] Relative paths for patch files in composer.json is incorrect</issue_title>
<issue_description>### Is there an existing issue for this?

• I have searched the existing issues

Current Behavior

One of the changes included in 20.16.0 is that composer.json uses relative paths for the patch files. That's only okay for final/leaf projects, not projects intended to be used as dependencies of other projects.

See: https://docs.cweagans.net/composer-patches/usage/defining-patches/#dependencies

As a result, installation of a new project fails because composer-patches is looking for the patch files at the root of the downstream project instead of the root of the Magento project.

Expected Behavior

composer install should work and not fail

Steps To Reproduce

1. Start new PHP project
2. Add openmage/magento-lts:20.16.0 as dependency
3. composer install

Environment

- OpenMage: 20.16.0
- php: N/A

Anything else?

No response</issue_description>

Comments on the Issue (you are @copilot in this section)

• Fixes [BUG] Relative paths for patch files in composer.json is incorrect #5214

---

💬 We'd love your input! Share your thoughts on Copilot coding agent in our 2 minute survey.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[github-actions]

Test Results

966 tests  ±0   958 ✅ ±0   18s ⏱️ +2s
213 suites ±0     8 💤 ±0 
  1 files   ±0     0 ❌ ±0 

Results for commit f9e41f4. ± Comparison against base commit 533b2a7.

♻️ This comment has been updated with latest results.

[Copilot]

Pull request overview

This PR fixes a bug where the ECG-72 patch used a relative path that fails when openmage/magento-lts is installed as a dependency in other projects. Per composer-patches documentation, relative paths in dependencies resolve from the consumer's root, not the package root.

• Changed ECG-72 patch path from relative (.vendor-patches/ECG-72.patch) to absolute GitHub URL
• Updated patches.lock.json to reflect the new URL and recalculated configuration hash
• Ensured consistency with all other patches which already use absolute GitHub URLs

Reviewed changes

Copilot reviewed 2 out of 3 changed files in this pull request and generated no comments.

File	Description
composer.json	Updated ECG-72 patch URL from relative path to absolute GitHub URL matching the pattern of other patches
patches.lock.json	Updated patch URL and recalculated _hash to reflect composer.json changes
composer.lock	Updated content-hash as expected when composer.json changes

[sreichel]

You can merge too.