App Bundle Laravel Package

Getting Started

This is a low-adoption (3 stars, 0 dependents) infrastructure bundle published by Gdbots, most likely extracted from their own Symfony applications. Treat the source as the documentation.

v4.0.0 changes the rules before you install anything. The only change in this release is a platform bump: Symfony 8.x and PHP 8.5+. There are no new features and no documented API changes, so the migration risk is almost entirely environmental, not behavioural. Check your app before you require:

php -v                       # need 8.5.x
composer show symfony/framework-bundle | grep versions
composer why-not gdbots/app-bundle 4.0   # shows what blocks the v4 constraint

If you are not on PHP 8.5 and Symfony 8, pin the previous major deliberately ("gdbots/app-bundle": "^3.0") rather than letting Composer pick a resolution. Assume 3.x is now in maintenance-only territory given the zero-dependents project has no reason to backport.

Minimal setup (on v4):

1. composer require gdbots/app-bundle:^4.0. Confirm the composer.json platform block matches PHP 8.5 and symfony/*: ^8.0 exactly — a small bundle like this typically pins its Symfony range tightly.
2. Register it in config/bundles.php:

   return [
       // ...
       Gdbots\Bundle\AppBundle\GdbotsAppBundle::class => ['all' => true],
   ];
   

3. Dump the container (bin/console cache:clear) and inspect what it registered:

   bin/console debug:container --tag=kernel.event_subscriber
   bin/console config:dump-reference gdbots_app
   

   If config:dump-reference returns nothing, the bundle has no configuration tree and is purely service wiring.

First place to look: src/DependencyInjection/ (the Extension/Configuration classes or the AbstractBundle subclass) and any Resources/config/services.yaml|xml or config/ directory. Re-read this on the 4.x branch even if you knew 3.x — a major that bumps to Symfony 8 is a natural moment to also modernise the bundle to AbstractBundle, move service files out of Resources/config, and switch to attribute-based autoconfiguration. The release notes don't say they did, but don't assume they didn't.

First use case: standing up a Gdbots-style Symfony app where this bundle supplies the shared plumbing (HTTP client, serializer/PBJ integration, logging, common subscribers) so your app code only contains domain logic. If you are not already inside the Gdbots ecosystem, evaluate whether the wiring it provides is worth the coupling — the bundle's value is proportional to how much of the surrounding gdbots stack you use.

Implementation Patterns

Configuration-driven wiring. Put app-specific overrides in config/packages/gdbots_app.yaml and environment overrides in config/packages/{env}/. Because the bundle is thin, most day-to-day changes are config edits rather than code.

Decorating bundle services. Rather than editing the bundle, decorate the services it registers:

services:
  App\Service\MyClient:
    decorates: gdbots_app.some_client
    arguments: ['@App\Service\MyClient.inner']

On Symfony 8 you can collapse this to an attribute and let autoconfiguration handle it:

#[AsDecorator('gdbots_app.some_client')]
final class MyClient implements ClientInterface { /* ... */ }

Use bin/console debug:container <service_id> to find the real IDs — they commonly use a gdbots_app. prefix, but verify rather than assume.

Event subscribers over bundle hooks. If the bundle dispatches kernel or domain events, subscribe from your app instead of extending bundle classes. This keeps upgrades cheap:

#[AsEventListener(event: KernelEvents::REQUEST, priority: 0)]
final class AppListener
{
    public function __invoke(RequestEvent $event): void { /* ... */ }
}

Compose with sibling gdbots bundles. Check whether gdbots/pbj, gdbots/pbjx, or a transport package also shipped a Symfony 8 / PHP 8.5 major. If this bundle is on v4 but its siblings are still on Symfony 7, you have an unresolvable dependency graph — this is the single most likely reason v4.0.0 is unusable for you today. Resolve the whole gdbots set to Symfony 8, or stay on the Symfony 7 line across all of them.

Register order. Register the app bundle after the lower-level ones so autoconfiguration and compiler passes see their services.

Use it as a reference implementation. The most practical day-to-day use outside the Gdbots ecosystem is reading its service definitions and compiler passes as a template for how to wire your own Symfony 8 app around the same libraries.

Gotchas and Tips

• PHP 8.5 is a hard floor, not a soft one. The failure mode is an opaque Root composer.json requires gdbots/app-bundle ^4.0 -> satisfiable by ... requires php >=8.5 during resolution, often several dependencies deep from the actual cause. Run a composer update gdbots/app-bundle --with-all-dependencies --dry-run before touching your lockfile.
• 4.x may contain PHP 8.5-only syntax. If you fork or backport service definitions to an older runtime, don't assume the code is copy-paste portable; new language features in a major rewrite are not flagged in release notes like this one.
• Symfony 8 removals bite bundle-adjacent config. Annotations, the old bundle directory conventions, and long-deprecated framework options are gone. If your config/packages/gdbots_app.yaml came from a Symfony 6/7 app, it may reference keys that no longer exist — expect to fix config around the bundle, not inside it.
• Sparse public documentation. No docs site, no dependents, low stars. Budget time for reading src/ end-to-end; it is small enough to do in an hour.
• Symfony version drift, inverted. The old warning ("unlikely to be tested against the newest major") no longer applies: v4 is only built for the newest major. The risk has flipped — it is now untested against everything older, and 3.x will not receive fixes. Decide your Symfony target first, then pick the bundle major.
• Bundle registration order matters if it decorates or replaces services registered by another bundle. If something silently stops working, temporarily move it to the end of config/bundles.php to confirm.
• Config cache staleness. After changing bundle config, always cache:clear; stale compiled containers are the most common source of "my config is ignored."
• No configuration tree? config:dump-reference failing usually means the extension has no Configuration class — don't waste time hunting for keys that don't exist.
• Extension points to prefer: service decoration, tagged services, and event subscribers. Avoid extending bundle classes or overriding files shipped in the bundle, because those break on minor upgrades — and a major like this one is where such overrides usually get invalidated.
• Debugging: bin/console debug:container --show-private | grep gdbots and bin/console debug:event-dispatcher are your fastest paths to understanding what the bundle actually does at runtime.
• Testing: load the bundle in your KernelTestCase kernel and assert on container services rather than on internal classes — this keeps your tests resilient to bundle refactors and to the next major.
• Exit strategy: zero dependents plus a permissive license (Apache-2.0) means you should be ready to fork or inline the handful of service definitions you actually use. Keep your integration surface (decorators, subscribers) narrow so this stays a one-day job — and note that the v3→v4 jump is exactly the kind of event that strands a small bundle, so keep the fork path current rather than theoretical.