Runtime Composer utility \Composer\InstalledVersions::getInstallPath( 'woocommerce/action-scheduler' ) does not work with jetpack-autoloader

[remcotolsma]

Impacted plugin

None / Other

Quick summary

To load Action Scheduler into one of our plugins we use the following code:

$action_scheduler_path = InstalledVersions::getInstallPath( 'woocommerce/action-scheduler' );

require_once $action_scheduler_path . '/action-scheduler.php';

This works if we use the default Composer autoload file:

require_once __DIR__ . '/vendor/autoload.php';

If we switch to https://github.com/automattic/jetpack-autoloader we get an error:

Fatal error: Uncaught Error: Class "Composer\InstalledVersions" not found

Or:

Fatal error: Uncaught OutOfBoundsException: Package "woocommerce/action-scheduler" is not installed 

Steps to reproduce

I have created a test plugin to reproduce the issue:
https://github.com/remcotolsma/reproduce-composer-utility-issue-with-jetpack-autoloader

A clear and concise description of what you expected to happen.

It would be nice if the runtime Composer utilities still work with the Jetpack autoloader.

What actually happened

The runtime Composer utilities are not available or the utility classes are not aware of the packages loaded via the Jetpack autoloader.

Impact

Some (< 50%)

Available workarounds?

There is no user impact

Platform (Simple and/or Atomic)

No response

Logs or notes

No response

[anomiex]

At first glance, one way to fix this could involve merging data similar to what Composer stores to vendor/composer/installed.php via Composer\InstalledVersions::reload(). But first we'd need to correctly merge together the data from each jetpack-autoloader-using plugin so the versions and paths are correct and identify a good place to merge the data in.

As a workaround for now, you might try using $jetpack_autoloader_loader->find_class_file() to find a relevant class from the package you're working with.

[github-actions]

This issue has been marked as stale. This happened because:

• It has been inactive for the past 6 months.
• It hasn’t been labeled `[Pri] BLOCKER`, `[Pri] High`, `[Type] Feature Request`, `[Type] Enhancement`, `[Type] Janitorial`, `Good For Community`, `[Type] Good First Bug`, etc.

No further action is needed. But it's worth checking if this ticket has clear reproduction steps and it is still reproducible. Feel free to close this issue if you think it's not valid anymore — if you do, please add a brief explanation.

[remcotolsma]

As a workaround for now, you might try using $jetpack_autoloader_loader->find_class_file() to find a relevant class from the package you're working with.

I don't think this will work in our use case. We need to include the woocommerce/action-scheduler/action-scheduler.php file. It appears that this file does not contain a class: https://github.com/woocommerce/action-scheduler/blob/cdb3ec83e3b914cdf607b68313e80c80b4566de0/action-scheduler.php.

[davemart-in]

@obenland this one doesn't look like something that a groundskeeper would pick up. Should this just be assigned to a team? I'll leave it alone, but figured you might have an opinion.

[obenland]

@jeherve Is the One Board the best place for this issue? Is there a Jetpack specific board where it would fit better?

[jeherve]

The issue is already assigned to the right team in the One Board, so it's on their radar:

That said, until now we didn't automatically add Autoloader issues to their Project boards ; we can do that too, so I just enabled it in #39958.

All this to say, I think the team is aware of that issue already. 👍