Bus Laravel Package

Getting Started

garlic/bus is a Symfony 4 bundle, not a Laravel package — there is no auto-discovered service provider, no config/bus.php, and no facade. As a Laravel developer your first move is to decide whether you're integrating it or mining it for patterns, because its Symfony 4.4-era constraints will not co-install cleanly with Laravel 9+. Laravel's own symfony/messenger / symfony/console / symfony/http-foundation constraints (Symfony 6/7 in recent versions) collide with a bundle written against Symfony 4.4.

The new 1.6.17 release is a single-line bugfix — "Fix event processor" — so nothing in the above changes. It is a patch on the event-bus path, not new Laravel integration, not a new feature, not a dependency bump. Do not re-run your evaluation expecting different composer results.

Minimal steps if you want to see it actually run:

1. composer require garlic/bus — expect a dependency conflict. The realistic sandbox is a fresh Symfony 4.4 skeleton, not a Laravel app.
2. Read the boot path first: src/GarlicBusBundle.php, then everything under DependencyInjection/ and Resources/config/. That is where the message bus aliases, service IDs, and middleware chain are declared. Everything else is a thin layer over Symfony Messenger.
3. If you care about the 1.6.17 change specifically, go straight to the event processor / event-bus wiring under DependencyInjection/ and the event-dispatcher subscriber — that is the only thing the patch touches.
4. First use case: define a message, a handler, dispatch from a controller — the canonical Symfony Messenger flow.

final class RegisterUser { public function __construct(public string $email) {} }

class RegisterUserHandler
{
    public function __invoke(RegisterUser $m) { /* ... */ }
}

$bus->dispatch(new RegisterUser('[email protected]'));

If you're staying in Laravel, skip steps 1–4 and read the source as a reference implementation of a middleware-pipelined bus. Your entry point is Illuminate\Bus\Dispatcher and Bus::pipeThrough().

Implementation Patterns

Garlic Bus follows the CQRS-lite convention common to Symfony bundles of that era: separate command, query, and event buses, each assembled from a shared middleware stack. In a Symfony context that means three bus aliases injected into services, one handler per message, and transport routing in config/packages/messenger.yaml.

• Handler registration — via tagged services / autoconfigure, not Laravel's EventServiceProvider::$listen array.
• Middleware — the layer you actually care about. Typical ordering is transaction wrapping → validation → logging → routing. The Laravel analogue is Bus::pipeThrough([...]) or job middleware (middleware() on the job class), which is the same shape.
• Async — handled by Symfony Messenger transports (AMQP/Doctrine/Redis). Laravel's analogue is a queued Job on a named connection, or dispatch(new X)->onQueue('events').
• Event processor — the 1.6.17 patch is confined to this path (the piece that pumps the event bus into Symfony's EventDispatcher). It is a correctness fix for an existing flow, so the pattern is unchanged: events are dispatched as messages whose handlers are ordinary subscribers.

Integration tips for a Laravel app:

1. Translate the middleware concept, not the container wiring. Wrap your dispatch path in a pipeThrough list so you get the same transactional/logging envelope.
2. Map the command/query/event split onto three contracts — queued ShouldQueue jobs for commands, synchronous handlers for queries, ShouldBroadcast/events for events — rather than building three literal bus instances.
3. If you're bridging to Symfony microservices that already speak this bundle, the transport wire format is what matters. Serialize as messenger envelopes with stamps, and make your Laravel producer/consumer honor that format. You do not need the bundle on the Laravel side to speak it.
4. Reuse the abstraction in tests: Bus::fake() mirrors mocking MessageBusInterface — assert against the message object, not the bus.

Bus::pipeThrough([
    WrapInTransaction::class,
    LogDispatch::class,
])->dispatch(new RegisterUser('[email protected]'));

Gotchas and Tips

• Abandonment risk is still the headline. A 1.6.17 patch landing does not make this maintained in any meaningful sense: 6 stars, 0 dependents, a Symfony 4 branch EOL since November 2023, and a two-word changelog. Patch-level activity on a legacy Symfony 4 line is maintenance-of-convenience, not a revival. Do not put it on a critical path.
• Don't over-read the 1.6.17 release. "Fix event processor" is a bugfix, not a compatibility release — it does not relax the Symfony 4.4 constraints, and it says nothing about Laravel support. Your install conflict analysis from before stands verbatim; there is no reason to re-test and no reason to expect a different outcome.
• Symfony 4 dependency constraints. Its symfony/* requirements fight Laravel's own. Even an --ignore-platform-reqs install leaves you with two container abstractions and no clear owner of the boot process — don't.
• No service provider. If you insist on using it inside Laravel, you must build a provider that registers the bundle's services on Laravel's container; the bundle assumes a Symfony Kernel + ContainerBuilder. This is where most people bounce.
• If you do pull 1.6.17, re-test the event path specifically. The one thing that changed is the event processor, so a regression there is the only plausible new failure mode — exercise your event-bus dispatch/subscriber loop before anything else, and pin the exact version rather than floating on ^1.6.
• Serialization quirks. The stamps/envelope layer is where message-bus bugs hide — custom stamps must serialize across the transport, and anything carrying models/entities breaks on async. Keep payloads to scalar DTOs.
• Debugging differs from what you know. In Symfony use the profiler plus messenger:consume -vv. In Laravel the equivalents are php artisan queue:work -vv, queue:failed, Telescope's Jobs/Events panels, and a logging middleware at the front of pipeThrough.
• Extension points worth stealing: a transactional-dispatch middleware, a Stamp-style marker interface for "dispatch after commit" (mirror with DB::afterCommit), and a message-class → transport routing table in config.
• If you truly need more than Laravel's queue (multiple buses, complex middleware, routing by message class), reach for symfony/messenger standalone — it's the maintained upstream this bundle wraps — not this bundle.
• Verdict: unchanged. Don't adopt as a dependency; 1.6.17 does not move the needle. Read it as a one- or two-hour reference for bus middleware ordering, then implement the pattern with Laravel's native Bus + Queue + Event primitives, which are maintained and already fit your container.