Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

Refactor WebAppAdapter::start() and ConsoleAppAdapter::start() into structured runtime pipelines

Abierto
#537 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
35/100
Tipo de issue
Refactorización
Claridad
Bastante claro
Estado de actividad
Tranquilo
Stack tecnológico
php
Área
backend

Línea de trabajo

Comienza con src/App/Adapters/WebAppAdapter.php y src/App/Adapters/ConsoleAppAdapter.php, y luego sigue los traits relacionados y src/App/BootPipeline.php. Compara los flujos actuales de start() con RouteDispatcher.php y MiddlewareManager.php para trazar el estado de ejecución y las responsabilidades. Se considera terminado cuando ambos adapters usan pipelines de ejecución y objetos de contexto dedicados, preservando el comportamiento web y de consola indicado; actualiza las pruebas según sea necesario.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

runtime

Summary

Refactor WebAppAdapter::start() and ConsoleAppAdapter::start() so runtime execution is no longer handled as flat sequences of loosely connected method calls.

Introduce structured runtime pipelines for web and console flows, similar in spirit to boot stages, so execution becomes explicit, extensible, and ready for future lifecycle hooks.

Why

The constructor already has a clear staged boot flow through BootPipeline, but runtime execution is still handled ad hoc.

In WebAppAdapter::start(), current responsibilities are mixed together in one method:

  • preflight handling
  • route resolution
  • not found handling
  • language loading
  • debug info logging
  • view cache setup
  • cached response lookup
  • route dispatch
  • middleware execution
  • response sending
  • request cleanup

In ConsoleAppAdapter::start(), runtime execution is also flat:

  • core command registration
  • app command registration
  • command validation
  • command execution

This makes both runtime flows harder to reason about and leaves no clean structural boundaries for future lifecycle hooks.

Goal

Create proper runtime execution structures for both web and console adapters before introducing broader lifecycle hooks.

Runtime flow should become stage-based rather than remaining collections of ad hoc method calls.

Proposed Direction

Introduce dedicated runtime pipelines instead of reusing BootPipeline directly.

Suggested runtime structures:

  • RequestPipeline
  • RequestContext
  • ConsolePipeline
  • ConsoleContext

These should carry evolving runtime state rather than relying on loose locals and inline control flow.

Suggested Web Runtime Stages

A reasonable first breakdown of the current web flow is:

  • HandlePreflightStage
  • ResolveRouteStage
  • HandleRouteNotFoundStage
  • PrepareRequestStage
  • DispatchRequestStage
  • SendResponseStage
  • CleanupRequestStage

Notes:

  • PrepareRequestStage should cover:
    • language loading
    • debug info logging
    • view cache setup
  • DispatchRequestStage should cover:
    • cached response lookup
    • route dispatch
    • middleware execution

Suggested Console Runtime Stages

A reasonable first breakdown of the current console flow is:

  • RegisterCoreCommandsStage
  • RegisterAppCommandsStage
  • ValidateCommandStage
  • RunCommandStage

If needed, command registration can later be collapsed into a single preparation stage, but the first refactor should prioritize clarity.

Scope

This ticket is about refactoring runtime structure for both adapters.

It should not yet define the full lifecycle hook contract. That should come after runtime flow has proper structural boundaries.

Acceptance Criteria

  • WebAppAdapter::start() is refactored into a structured runtime pipeline
  • ConsoleAppAdapter::start() is refactored into a structured runtime pipeline
  • runtime state is carried through dedicated runtime context objects rather than loose local variables
  • web runtime responsibilities such as language loading and view cache handling are preserved in the new structure
  • console runtime responsibilities such as command registration, validation, and execution are preserved in the new structure
  • the new runtime structures are suitable for later lifecycle hook integration
  • tests are updated as needed

Notes

Relevant code:

  • src/App/Adapters/WebAppAdapter.php
  • src/App/Adapters/ConsoleAppAdapter.php
  • src/App/Traits/WebAppTrait.php
  • src/App/Traits/ConsoleAppTrait.php
  • src/Router/RouteDispatcher.php
  • src/Middleware/MiddlewareManager.php
  • src/App/BootPipeline.php

This ticket should be completed before introducing broader runtime lifecycle hooks.

Lenguaje dominante
PHP
Estrellas
36
Forks
22
Métricas de merge de PR
Sin PR fusionados en 30 d

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de quantum-php/framework

Todos los issues de quantum-php/framework

Issues similares

Más issues de PHP

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.