Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Remove Loader as a top-level package and split its responsibilities across Config, Environment, and helper boot

Aperta
#535 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
45/100
Tipo di issue
Refactoring
Chiarezza
Abbastanza chiara
Stato di attività
Tranquilla
Stack tecnologico
php
Ambito
backend

Direzione di ricerca

Inizia tracciando le responsabilità e gli utilizzi in src/Loader/Loader.php, src/Loader/Setup.php, src/Config/Config.php, src/Environment/Environment.php, src/Storage/Uploads/UploadConfigProvider.php e src/App/Stages/LoadHelpersStage.php. Verifica il comportamento esistente di risoluzione gerarchica e individua i test e la documentazione interessati prima di separare le responsabilità. Il lavoro è completato quando Loader non è più un package di primo livello, i nuovi responsabili preservano un comportamento compatibile e i test e la documentazione sono aggiornati secondo necessità.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

config

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
Lingua principale
PHP
Stelle
36
Fork
22
Metriche di merge delle PR
Nessuna PR unita negli ultimi 30g

Guida per i contributori

Apri la guida per i contributori

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di quantum-php/framework

Tutte le issue di quantum-php/framework

Issue simili

Altre issue su PHP

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.