Weave Code
Laravel Eventsauce Laravel Package
eventsauce/laravel-eventsauce
Laravel integration for EventSauce event sourcing. Wire message dispatchers, event repositories, and consumers into Laravel’s container with publishable config, queue-friendly dispatching, and conventions for aggregates and projections in Laravel applications.
Integration support for EventSauce with the Laravel framework.
Frequently asked questions about Laravel Eventsauce
- What is eventsauce/laravel-eventsauce and what does it actually do?
- It is a thin Laravel integration layer for the EventSauce event sourcing library. It registers a service provider, ships publishable configuration, and binds EventSauce abstractions such as aggregate repositories and message dispatchers into Laravel's container. It does not add persistence, projections, or schema management of its own, so you still bring your own message repository and snapshot strategy. Think of it as glue between EventSauce and familiar Laravel workflows rather than a standalone event sourcing framework.
- How do I install eventsauce/laravel-eventsauce in a Laravel app?
- Install it with Composer using composer require eventsauce/laravel-eventsauce, then publish the configuration with the vendor:publish Artisan command. Laravel's package auto-discovery registers the service provider, so manual registration is normally unnecessary. After publishing you edit the config file to point at your message repository and dispatcher implementations. On a greenfield project running a currently supported PHP version, the whole setup is typically a sub-day task.
- Which Laravel and PHP versions does this package support?
- Version 0.5.0 targets EventSauce 1.x, which modernizes the bridge, but the release notes describe only that upstream dependency upgrade. The illuminate/* constraints and PHP ceiling are not stated there, so verify the require section of composer.json before you plan an upgrade. Do not assume Laravel 10 or 11 and PHP 8.2 or 8.3 support without checking that file. The older 0.4.x line predated those versions, so older write-ups are not a reliable guide.
- Is 0.5.0 a breaking change from 0.4.0?
- Yes. Anything wired against the EventSauce 0.x message dispatcher, message consumer, repository, or snapshot interfaces will not resolve against 1.x. If you built a spike or sandbox on 0.4.0, treat it as a rewrite of the wiring rather than a straight upgrade. The glue itself is small, so migrating usually means updating bindings and configuration. The package is still versioned 0.x, so further breaking changes between minor releases remain permitted.
- Do I still need a message repository and database tables?
- Yes. The package provides no persistence, projections, or schema management of its own; it only wires EventSauce abstractions into Laravel's container. You supply a message repository, commonly Doctrine DBAL or a custom implementation, plus a snapshot strategy if you need one. Laravel's database infrastructure is available for that, but the storage design and migrations remain your responsibility.
- How do I generate an aggregate root with Artisan?
- The package registers Artisan commands for scaffolding aggregates and supporting classes so they follow EventSauce conventions. Run the generator with your aggregate name and it produces a class skeleton you then fill in with behaviour methods and event application logic. Using the generators keeps naming and namespace conventions consistent across a codebase, which matters once you have several aggregates and consumers.
- Can I run consumers and projections on Laravel queues?
- Yes. The package integrates with Laravel's queue infrastructure and supports queue-friendly message dispatching and consumption. That lets you process reactions to domain events asynchronously with standard queue workers, which is the usual way to drive projections or side effects. You still configure connections and workers yourself; the package supplies the wiring, not the operational setup.
- How do I test event-sourced code built with this package?
- Because the bindings live in Laravel's container, you can swap in in-memory or fake repositories and dispatchers inside your normal Laravel test cases. Aggregates themselves are plain EventSauce classes, so they can be unit tested without booting the framework at all. Most teams test aggregate behaviour in isolation and reserve feature tests for container wiring and the queue dispatch path.
- Does this package give me projections, read models, or schema management?
- No. It is deliberately thin glue: a service provider, publishable configuration, and container bindings. Projections, read models, and database schema management fall outside its scope and must be built or brought in separately. If you want an all-in-one event sourcing framework for Laravel, this package answers a smaller question than its name suggests.
- Should I use this package or write my own service provider?
- Because the package encodes few opinions and its glue surface is small, a hand-written service provider replicating the bindings remains a realistic alternative. Consuming the package is more attractive now that 0.5.0 tracks EventSauce 1.x and is maintained by the same author who defines the upstream interfaces, which reduces divergence risk. The trade-off is that it is still 0.x, with a single recent first-time contributor and little evidence of production adoption, so expect to debug failure modes from source. If you can accept that, the package saves you maintenance on a small but real piece of wiring.
Weaver
How can I help you explore Laravel packages today?