Summary
Refactor the current Loader package out of the top-level framework architecture.
Its responsibilities should be split into the places that actually own them:
- hierarchical config file resolution should belong to
Config
- environment bootstrap file resolution should belong to
Environment
- helper loading should be handled separately and should not justify
Loader remaining its own package
Why
Right now Loader acts like a standalone package, but the code shows it is mostly a shared utility for unrelated internal concerns.
Current usages include:
Config loading hierarchical config files
Environment loading env bootstrap config
UploadConfigProvider probing/loading optional uploads config
- helper directory loading during boot
This is a weak package boundary.
The most obvious mismatch is Environment: environment bootstrap should not depend on a separate generic loader package just to resolve a small config file that determines which .env file to load.
Current Behavior to Preserve
For config loading, preserve the current hierarchical resolution behavior:
- resolve the module-scoped file first
- if the setup is hierarchical and the module file does not exist, fall back to the shared file
For config imports that currently means:
modules/<module>/config/<file>.php
- then
shared/config/<file>.php
Proposed Changes
- remove
Loader as a standalone top-level package concept
- move hierarchical config file resolution into
Config
- move environment bootstrap file resolution into
Environment
- update
UploadConfigProvider so its optional config lookup follows the new ownership boundaries
- keep helper loading as a separate concern and do not let it define the long-term architecture of
Loader
Acceptance Criteria
Loader is no longer treated as a standalone top-level package
Config owns hierarchical config file resolution
Environment no longer relies on Loader for its bootstrap config resolution
UploadConfigProvider no longer relies on a generic top-level loader abstraction if a more local ownership model is available
- existing hierarchical config behavior remains compatible
- tests and docs are updated as needed
Notes
Relevant code:
src/Loader/Loader.php
src/Loader/Setup.php
src/Config/Config.php
src/Environment/Environment.php
src/Storage/Uploads/UploadConfigProvider.php
src/App/Stages/LoadHelpersStage.php
Summary
Refactor the current
Loaderpackage out of the top-level framework architecture.Its responsibilities should be split into the places that actually own them:
ConfigEnvironmentLoaderremaining its own packageWhy
Right now
Loaderacts like a standalone package, but the code shows it is mostly a shared utility for unrelated internal concerns.Current usages include:
Configloading hierarchical config filesEnvironmentloading env bootstrap configUploadConfigProviderprobing/loading optional uploads configThis is a weak package boundary.
The most obvious mismatch is
Environment: environment bootstrap should not depend on a separate generic loader package just to resolve a small config file that determines which.envfile to load.Current Behavior to Preserve
For config loading, preserve the current hierarchical resolution behavior:
For config imports that currently means:
modules/<module>/config/<file>.phpshared/config/<file>.phpProposed Changes
Loaderas a standalone top-level package conceptConfigEnvironmentUploadConfigProviderso its optional config lookup follows the new ownership boundariesLoaderAcceptance Criteria
Loaderis no longer treated as a standalone top-level packageConfigowns hierarchical config file resolutionEnvironmentno longer relies onLoaderfor its bootstrap config resolutionUploadConfigProviderno longer relies on a generic top-level loader abstraction if a more local ownership model is availableNotes
Relevant code:
src/Loader/Loader.phpsrc/Loader/Setup.phpsrc/Config/Config.phpsrc/Environment/Environment.phpsrc/Storage/Uploads/UploadConfigProvider.phpsrc/App/Stages/LoadHelpersStage.php