 |
VOOZH | about |
|
VOOZH | about |
This document provides a detailed explanation of the ProviderConfig system, the most critical component in the hypervel/config package (importance: 22.24). The ProviderConfig class is responsible for discovering configuration contributions from Composer packages, filtering packages based on discovery rules, loading provider configurations, and merging them into a unified configuration array using sophisticated merge algorithms.
For information about how ConfigFactory orchestrates the overall configuration loading process, see Configuration Factory. For details about the merge algorithm's behavior with specific data structures, see Configuration Merging Strategies.
Sources: src/ProviderConfig.php1-169
The ProviderConfig class extends Hyperf\Config\ProviderConfig and provides the discovery and merging infrastructure for package-contributed configurations. It serves as the bridge between Composer's package metadata and the application's configuration system.
Diagram: ProviderConfig System Architecture
Sources: src/ProviderConfig.php17-169
The load() method is the entry point for configuration discovery. It implements a caching mechanism to avoid redundant package discovery on subsequent calls.
Diagram: Configuration Discovery Flow
Sources: src/ProviderConfig.php26-54
The load() method discovers configuration providers from three Composer extra keys for each package:
| Source Key | Description | Example Usage |
|---|---|---|
hyperf.config | Standard Hyperf configuration providers | Legacy Hyperf packages |
hypervel.config | Hypervel-specific configuration providers | Hypervel packages |
hypervel.providers | Explicit provider class list | Custom service providers |
The discovery logic at src/ProviderConfig.php37-44 merges all three sources:
Each package's configuration entries are wrapped with Arr::wrap() to ensure array type, merged together, and then flattened into a single provider list.
Sources: src/ProviderConfig.php37-53
The packagesToIgnore() method implements package discovery filtering through the hypervel.dont-discover configuration key. This allows applications to exclude specific packages from automatic configuration discovery.
Diagram: Package Filtering Mechanism
The filtering logic merges two sources:
Composer::getMergedExtra('hypervel')['dont-discover']composer.json at extra.hypervel.dont-discoverA special wildcard value * disables all automatic discovery at src/ProviderConfig.php33-35
Sources: src/ProviderConfig.php77-88
The loadProviders() method processes the discovered provider class names and extracts configuration from them. It supports two patterns:
Diagram: Provider Loading Logic
Sources: src/ProviderConfig.php56-75
For classes that extend Hypervel\Support\ServiceProvider, the system calls the static getProviderConfig() method at src/ProviderConfig.php63-67:
This pattern allows service provider classes to contribute configuration in a declarative manner.
Sources: src/ProviderConfig.php63-68
For classes that implement the __invoke() method, the system instantiates the class and calls it as a function at src/ProviderConfig.php69-71:
This pattern provides flexibility for dynamic configuration generation.
Sources: src/ProviderConfig.php69-72
The merge() method accepts multiple configuration arrays and reduces them into a single merged result using the mergeTwo() method as the reduction function.
Diagram: Multi-Array Merge Process
The method at src/ProviderConfig.php100-131 performs two operations:
array_reduce() with mergeTwo() as the callbackdependencies keySources: src/ProviderConfig.php100-131
The mergeTwo() method implements the core merge semantics, handling different key types and value types appropriately. This method is public to allow ConfigFactory to use the same merge logic at src/ProviderConfig.php145
Diagram: mergeTwo() Algorithm Flow
The algorithm at src/ProviderConfig.php145-168 handles three cases:
| Case | Key Type | Behavior | Code Reference |
|---|---|---|---|
| Numeric keys | is_int($key) | Append with deduplication using in_array() | src/ProviderConfig.php150-154 |
| New string keys | String key not in base | Add directly to result | src/ProviderConfig.php155-157 |
| Existing string keys (arrays) | String key, both values are arrays | Recursive merge via mergeTwo() | src/ProviderConfig.php158-160 |
| Existing string keys (scalars) | String key, non-array values | Override with new value | src/ProviderConfig.php161-163 |
Sources: src/ProviderConfig.php145-168
The merge() method includes special logic for the dependencies key, which contains dependency injection definitions that may use PriorityDefinition objects to control instantiation order.
Diagram: PriorityDefinition Merge Logic
The logic at src/ProviderConfig.php112-128 ensures that:
dependencies key is completely reset (not recursively merged)PriorityDefinition instances, they are merged using the merge() method of PriorityDefinitionPriorityDefinition values override existing valuesThis preserves the priority-based dependency ordering required by Hyperf's dependency injection system.
Sources: src/ProviderConfig.php112-128
The ProviderConfig class implements a static cache to avoid redundant package discovery and merging on subsequent calls to load().
Diagram: Static Cache Mechanism
The cache check at src/ProviderConfig.php28-30 returns immediately if $providerConfigs is not empty:
The cache is populated at src/ProviderConfig.php51-53 after successful discovery and merging.
The comment at src/ProviderConfig.php24 mentions a clear() method for resetting the cache, though this method is not present in the file (likely inherited from HyperfProviderConfig).
Sources: src/ProviderConfig.php19-30 src/ProviderConfig.php51-53
Diagram: ProviderConfig Class Dependencies
Sources: src/ProviderConfig.php1-169
While ProviderConfig::load() is typically called internally by ConfigFactory, it can also be invoked directly:
The returned array contains all configuration keys contributed by discovered providers, merged according to the algorithm described above.
Sources: src/ProviderConfig.php26-54
Refresh this wiki