Огляд ConceptStack

Extensions Concept 2 — окремі пакети з власними ServiceProvider. Без Stack ви вручну збираєте десятки new XxxServiceProvider(...), пам’ятаєте порядок залежностей і дублюєте wiring у кожному glue. Це швидко ламається, коли з’являються FormRequest → Validation, ErrorHandling → Logging, View → Http.

php-concept/stack знімає саме цей біль: fluent addX() реєструє capability і повертає builder. Після збірки $stack->providers() — упорядкований список providers для League Container. Stack не читає config і нічого не вмикає «за компанію»: якщо не викликали addSession() — сесії в контейнері немає.

$stack = ConceptStack::create();

$stack->addHttp()
    ->setRoutes([$rootPath . 'routes/web.php']);

foreach ($stack->providers() as $provider) {
    $container->addServiceProvider($provider);
}

Неймінг: навіщо префікси

Префікси методів — не косметика, а підказка «що робить виклик» без читання сигнатури. Один раз зрозумівши таблицю, легше читати чужий Bootstrap і не плутати обов’язковий конфіг з opt-in.

ПрефіксРольПриклад
add* Entry capability на StackBuilder — «увімкнути можливість» addHttp(), addView()
set* Обов’язковий або явний конфіг / значення на brick setRoutes(), setConnection()
with* Opt-in feature або sub-builder — «коли треба, не за замовчуванням» withFormRequests(), withTwig()
to* Sink (куди писати) — типово Logging toRotatingFile(), toStderr()

Принципи

Ці правила пояснюють, чому Bootstrap виглядає явно, а не «магічно»:

  • Stack не читає config — лише arguments на brick-методи. Тоді один і той самий brick працює в Docker, CLI і тестах без прихованих файлів.
  • addX() одразу реєструє capability (без end()): ви бачите в Bootstrap рівно те, що потрапить у контейнер.
  • Залежності між capabilities — через require() у builder (наприклад HTTP → validation для FormRequest). Помилка збірки раніше, ніж runtime «class not found».
  • Додаткові app providers — $stack->addProvider(...), коли glue-сервіс не є загальним brick.

Куди далі

Довідники bricks — у тому ж порядку, що й кроки рецептів: