With composer 2.0 patch is applied, but not listed in composer.lock [extra][patches_applied]

[ndf]

While upgrading to composer 2.0 we noticed that the patches still apply (so no functional regression), but are not visible anymore in composer.lock.

Can [extra][patches_applied] be added back? IMO it helpful when reviewing PRs that contain code updates.

Example composer.lock with composer 1.0

"type": "drupal-module",
"extra": {
    "drupal": {
        "version": "8.x-1.6",
        "datestamp": "1589312204",
        "security-coverage": {
            "status": "covered",
            "message": "Covered by Drupal's security advisory policy"
        }
    },
    "patches_applied": {
        "#2948211: Front page redirects break the canonical link.": "https://www.drupal.org/files/issues/2020-04-22/fix_front_page-2948211-11.patch"
    }
},

And composer.lock with composer 2.0

"type": "drupal-module",
"extra": {
    "drupal": {
        "version": "8.x-1.6",
        "datestamp": "1589312204",
        "security-coverage": {
            "status": "covered",
            "message": "Covered by Drupal's security advisory policy"
        }
    }
},

[recrit]

+1 for this to be added back to the composer.lock. It provides the audit trail of "what is installed" (composer.lock) vs "what you want to be installed" (composer.json)

[tgifford-webfirst]

This is tracked in vendor/composer/installed.json now. Make sure you have extra.composer-exit-on-patch-failure set to true.

[adam-delaney]

+1 to get this written back to the lock file.

[davereid-pfg]

Not being able to see the patches in the committed lock file worries me a lot, because it adds a layer of uncertainty that your local might be different from mine, or productions, with respect to what patches should be applied.

[jeremychinquistdrunomicscom]

+1 to get this written back to the lock file. ./vendor/composer/installed.json is not in our git repo. We do peer reviews of the composer.lock file. Seeing that the patches are installed and apply cleanly helps.

[cweagans]

Makes sense to me. I probably won’t have time to work on this in the near future but I’ll happily review a PR against either branch if someone wants to tackle this.

[hkirsman]

+1

[louis-cuny]

I think it is important to place it back

On composer install it should only use the listed patches in the composer.lock file. On composer validate it should check if all composer.json declared patches are mentioned in composer.lock.

[normanlolx]

We already agreed on this. Now someone needs to start working on it.

[kkohlbrenner]

+1 Heart skipped a beat until I saw > This is tracked in vendor/composer/installed.json now. 😅

[mxr576]

But vendor/composer/installed.json is not committed to VCS, so it is basically useless, the original behavior was better.

[skyred]

Here is a real example that this plugin has to keep track of the state:

Below the patch failed to apply because a network issue, then subsequent composer install shows no error, no warning, therefore, makes me believe all the patches have correctly applied.

Found 1 patches for drupal/webform_encrypt.
  - Installing drupal/webform_encrypt (1.0.0-beta1): Extracting archive
> post-package-install: cweagans\Composer\Patches->postInstall
  - Applying patches for drupal/webform_encrypt
    https://www.drupal.org/files/issues/2021-04-23/3210370-make-the-class-compatible-2.patch (Make the class WebformEncryptSubmissionStorage compatible with WebformSubmissionStorage class of the webform module version 6)
   Could not apply patch! Skipping. The error was: The "https://www.drupal.org/files/issues/2021-04-23/3210370-make-the-class-compatible-2.patch" file could not be downloaded: failed to open stream: Unable to find the socket transport "socks5" - did you forget to enable it when you configured PHP?

                                                                                                                                                                                           
  [Exception]                                                                                                                                                                              
  Cannot apply patch Make the class WebformEncryptSubmissionStorage compatible with WebformSubmissionStorage class of the webform module version 6 (https://www.drupal.org/files/issues/2  
  021-04-23/3210370-make-the-class-compatible-2.patch)!

[mxr576]

composer install shows no error, no warning, therefore, makes me believe all the patches have correctly applied.

Can you check if you have this configured on the project level?

https://github.com/cweagans/composer-patches#error-handling

What you described could have happened because you do not have this configured and having patches tracked in composer.lock probably would not prevent this.

[skyred]

Can you check if you have this configured on the project level?

Yes

[firewaller]

+1 to getting this re-added to composer.lock

[cweagans]

I asked Jordi how to go about doing this in a discussion and tl;dr, this approach isn't going to work very well in Composer 2 because of how Composer now works. Now, all dependencies are resolved and a lock file is written before anything is ever installed.

So now, we have patches.lock in main.

[geertvansoest]

@cweagans We are currently using 1.7.3 and added some patches into our composer.json file. The patches were applied, but no patches.lock file was created. Is this something being released in 2.x or are we missing something?

"extra": {
	"composer-exit-on-patch-failure": true,
	"patches": {
		"la-haute-societe/craft-elasticsearch": {
			"description": "patches/file.patch"
		}
	}
}

[cweagans]

Patches.lock only exists in 2.x.