AutoloadRuntime Package Discovery

The AutoloadRuntime class provides package discovery and classification services for the Maho autoloading system. It scans Composer's installed packages, filters by relevant package types (maho-source, maho-module, magento-module), and resolves their filesystem paths including modman symlink directories. This discovery mechanism serves as the foundation for include path generation, PSR-0 prefix mapping, and class map construction.

For information about how the AutoloadPlugin invokes these discovery methods during the autoload dump event, see AutoloadPlugin Implementation. For details on how discovered packages are organized into code pools, see Code Pool Structure and Priority. For the algorithms that consume the discovered package list to generate autoload mappings, see PSR-0 and Class Map Generation.

Sources: src/AutoloadRuntime.php7-15

Package Discovery Algorithm

The getInstalledPackages() method serves as the central discovery mechanism for all autoloading operations. It queries Composer's runtime API to retrieve installed package metadata, filters packages by type, and resolves their installation paths.

Package Discovery Flow for getInstalledPackages() Method

The algorithm implements several key behaviors:

1. Static Caching: Results are cached in $installedPackages to avoid repeated Composer API queries during a single PHP execution src/AutoloadRuntime.php18-19 src/AutoloadRuntime.php33-35

2. Composer Instance Filtering: Skips datasets where the root package is composer/composer to avoid processing the plugin development environment src/AutoloadRuntime.php42-44

3. Path Validation: Uses realpath() to validate both root and package installation paths exist on the filesystem src/AutoloadRuntime.php45-46 src/AutoloadRuntime.php57-59

4. Single Dataset Processing: Only processes the first valid dataset and breaks after collecting all its packages src/AutoloadRuntime.php74

Sources: src/AutoloadRuntime.php31-86

Package Type Classification

The discovery system recognizes three specific package types from Composer's package metadata. This classification determines how each package is processed by the autoloading system.

Package Type	Description	Example Package	Priority Order
maho-source	Core Maho framework package containing base code pools	mahocommerce/maho	1st (highest)
maho-module	Maho extension modules	mahocommerce/maho-sentry	2nd
magento-module	Legacy Magento 1 modules	firegento/magesetup	2nd

Package Type Classification Decision Tree

The type checking logic uses strict equality for maho-source and an array membership check for the two module types src/AutoloadRuntime.php68-72:

This classification ensures:

• Core framework packages are discovered first and take precedence in include paths
• Both Maho-native and legacy Magento modules are treated equivalently
• Non-Maho packages are excluded from autoload generation
• The root project package is always included regardless of its type

Sources: src/AutoloadRuntime.php68-72 src/AutoloadRuntime.php81-85

Symlink Directory Resolution

The discovery mechanism includes special handling for packages deployed via the ModmanPlugin. When a package has been symlinked through modman deployment, the discovery system prefers the symlink directory over the original vendor installation path.

Symlink Directory Resolution Logic

This resolution occurs for every package during discovery src/AutoloadRuntime.php60-62:

The symlink preference behavior has important implications:

• ModmanPlugin Integration: Packages deployed via modman have their symlink structure respected during autoload generation. This ensures that autoloading scans the symlinked files rather than the original vendor directory copies src/AutoloadRuntime.php60-62

• Path Consistency: When modman symlinks exist, all subsequent operations (include path generation, PSR-0 scanning, class map building) use the symlink directory paths

• Graceful Fallback: If no symlink directory exists, the original vendor installation path is used without error

This design allows the autoload system to seamlessly work with both standard Composer installs and modman-deployed modules.

Sources: src/AutoloadRuntime.php60-62

Package Ordering Strategy

The getInstalledPackages() method returns packages in a specific order that establishes precedence for code pool resolution and class loading. The ordering strategy is explicitly documented in the method's docblock src/AutoloadRuntime.php25-28

Package Array Ordering Diagram

The ordering is achieved through array spread operations src/AutoloadRuntime.php81-85:

This ordering serves different purposes in different contexts:

Forward Order Usage (as returned):

• Code Pool Discovery: Core framework code pools are scanned before module code pools src/AutoloadRuntime.php142-152
• Class Map Generation: Maho core classes like Mage are registered before module classes src/AutoloadRuntime.php206-214

Reverse Order Usage:

• Include Path Priority: The generateIncludePaths() method reverses the package array so that local/community code in the root project takes precedence over vendor packages src/AutoloadRuntime.php115-117 src/AutoloadRuntime.php142

The special 'root' key distinguishes the project root package from dependencies. This allows conditional logic such as skipping core code pools for the root package when it has type maho-source src/AutoloadRuntime.php143-146

Sources: src/AutoloadRuntime.php25-28 src/AutoloadRuntime.php81-85 src/AutoloadRuntime.php142

Package Data Structure

The package discovery system returns a structured array conforming to a specific type definition. This structure provides consistent access to package metadata throughout the autoloading system.

Type Definition src/AutoloadRuntime.php13-14:

Structure Diagram:

Package Data Structure with Example Values

Each package array contains three keys:

• name: The Composer package name (vendor/package format) src/AutoloadRuntime.php49 src/AutoloadRuntime.php64
• type: The Composer package type as declared in the package's composer.json src/AutoloadRuntime.php50 src/AutoloadRuntime.php65
• path: The absolute filesystem path to the package directory, resolved via realpath() and potentially pointing to a modman symlink src/AutoloadRuntime.php51 src/AutoloadRuntime.php66

The array keys are the package names except for the special 'root' key which holds the root project package src/AutoloadRuntime.php84

Sources: src/AutoloadRuntime.php13-14 src/AutoloadRuntime.php48-52 src/AutoloadRuntime.php63-67

Helper Methods Built on Package Discovery

The AutoloadRuntime class provides additional methods that leverage the package discovery system for specialized filesystem operations.

globPackages Method

The globPackages() method extends PHP's native glob() function to search across all discovered packages src/AutoloadRuntime.php89-110:

globPackages Search Flow

This method is used internally to discover module configuration files src/AutoloadRuntime.php217 and include files src/AutoloadRuntime.php262 It enables pattern-based searches such as:

• /app/code/*/*/* to find all module directories
• /app/etc/includes/*.php to find auto-include files
• /app/etc/modules/*.xml to find module declarations

The method concatenates results from all packages into a single flat array, maintaining the order of packages (maho-source first, then modules, then root) src/AutoloadRuntime.php102-106

Sources: src/AutoloadRuntime.php89-110 src/AutoloadRuntime.php217 src/AutoloadRuntime.php262

Integration with Composer InstalledVersions API

The package discovery mechanism interfaces directly with Composer's runtime API through the InstalledVersions class. This integration provides access to the installed package registry without parsing composer.lock or vendor metadata files.

InstalledVersions API Integration

The getAllRawData() method returns an array of datasets, where each dataset represents a Composer installation context src/AutoloadRuntime.php41:

Key Integration Points:

• The API is provided by the composer/composer dependency listed in composer.json composer.json
• The plugin only processes one dataset and breaks after the first valid one src/AutoloadRuntime.php74
• Datasets where the root is composer/composer itself are skipped to avoid self-referential discovery src/AutoloadRuntime.php42-44
• Failed realpath() resolutions cause packages to be silently skipped rather than throwing errors src/AutoloadRuntime.php45-46 src/AutoloadRuntime.php57-59

This design allows the discovery system to function correctly in both development environments (when the plugin is being developed) and production environments (when the plugin is installed in a Maho project).

Sources: src/AutoloadRuntime.php41-75 src/AutoloadRuntime.php5