AMP WP 2.0.6 breaks site due to PHP Fatal error: Uncaught OutOfBoundsException: Package "sentry/sentry" is not installed in [...]/wp-content/plugins/amp/vendor/composer/InstalledVersions.php:209

[archon810]

Bug Description

[18-Nov-2020 23:22:04 UTC] PHP Fatal error:  Uncaught OutOfBoundsException: Package "sentry/sentry" is not installed in /srv/www/htdocs/dev.SNIP.com/public/wp-content/plugins/amp/vendor/composer/InstalledVersions.php:209
Stack trace:
#0 /srv/www/htdocs/dev.SNIP.com/vendor/composer/package-versions-deprecated/src/PackageVersions/Versions.php(203): Composer\InstalledVersions::getPrettyVersion('sentry/sentry')
#1 /srv/www/htdocs/dev.SNIP.com/vendor/jean85/pretty-package-versions/src/PrettyVersions.php(13): PackageVersions\Versions::getVersion('sentry/sentry')
#2 /srv/www/htdocs/dev.SNIP.com/vendor/sentry/sentry/src/ClientBuilder.php(79): Jean85\PrettyVersions::getVersion('sentry/sentry')
#3 /srv/www/htdocs/dev.SNIP.com/vendor/sentry/sentry/src/ClientBuilder.php(87): Sentry\ClientBuilder->__construct(Object(Sentry\Options))
#4 /srv/www/htdocs/dev.SNIP.com/vendor/sentry/sentry/src/functions.php(17): Sentry\ClientBuilder::create(Array)
#5 /srv/www/htdocs/dev.SNIP.com/public/wp-content/plugins/ap-c in /srv/www/htdocs/dev.SNIP.com/public/wp-content/plugins/amp/vendor/composer/InstalledVersions.php on line 209

Expected Behaviour

AMP works.

Steps to reproduce

1. Update from 2.0.5 to 2.0.6 - site breaks due to above error.

Additional context

• WordPress version: 5.4.3
• Plugin version: 2.0.6
• AMP plugin template mode: Transitional
• PHP version: 7.4
• OS: Linux

---

Do not alter or remove anything below. The following sections will be managed by moderators only.

Acceptance criteria

Implementation brief

QA testing instructions

Demo

Changelog entry

[pierlon]

Posting my analysis from Slack:

So it seems to be due to the plugin getting the Composer\InstalledVersions namespace first, and when the composer/package-versions-deprecated package calls Composer\InstalledVersions::getPrettyVersion() our bundled composer answers to that, which shouldn't happen.

Seems the lead dev of composer was aware of this being a possibility composer/composer#8803 (comment)

And from @schlessera:

Right now, I think we could only solve this reliably be getting rid from 'Composer\InstalledVersions' in our own autoloader. However, this is added in a hard-coded way directly within the generation of the autoloader.

1. Can we strip the 'Composer\\InstalledVersions' => $vendorDir . '/composer/InstalledVersions.php', line from the autoloader during the plugin build step. This ensures that if multiple autoloaders are active, we don't rely on our autoloaders having this class and thus don't cause a conflict. However, one of our own dependencies might require it...?

2. Our autoloader should only be required if it is actually present within the folder. This allows a WordPress site built via a Composer stack to pull the plugin in via Composer and have a centralized autoloader. This is also what the site with the current issue should then do. Note that right now, we require the autoloader unconditionally, which will break on a site-wide Composer installation.

3. Also, the site that is currently breaking could use reload() immediately after requiring their own autoloader. I think that might solve the problem as well.

[westonruter]

Closing as fixed in 2.0.7 in #5610. We'll revisit upgrading to Composer v2 in AMP plugin 2.1+.