- Can I install jphooiveld/eventsauce-bundle in a Laravel application?
- No. It is a Symfony bundle that depends on bundle manifests, Kernel::registerBundles(), and services.yaml autoloading conventions that Laravel does not have. Composer will install it, but none of its dependency-injection wiring will run inside a Laravel app. Treat it strictly as reference source for how the EventSauce services are assembled.
- Does this package support Laravel 10 or Laravel 11?
- No. The bundle was last released in November 2019 and targets PHP 7.2 to 7.4 with Symfony 4.3 and 4.4, while Laravel 10 and 11 require PHP 8.1 or 8.2 and above. The dependency graph will not resolve on a modern Laravel platform. There is no Laravel service provider, facade, or config file in the package.
- What does the EventSauce bundle actually configure in the Symfony container?
- It wires the EventSauce infrastructure into Symfony's DI container: aggregate root repositories, the message dispatcher, message and snapshot repositories, and serializers for event persistence. The value of the package is that service map rather than any domain logic. That map is portable as knowledge, but the PHP code is Symfony-specific.
- How do I use EventSauce event sourcing in Laravel without this bundle?
- Use the underlying eventsauce/eventsauce library directly and hand-write a Laravel ServiceProvider. Bind MessageRepository, AggregateRootRepository, MessageDispatcher, and a serializer such as ConstructingMessageSerializer, backed by Doctrine DBAL or Eloquent for persistence. Reimplementing the bundle's wiring is a bounded task for an engineer already comfortable with EventSauce's interfaces.
- Is jphooiveld/eventsauce-bundle still maintained?
- It has not had a release since 2019-11-25, has a single maintainer, roughly 15 stars, and zero dependents on Packagist. There is no observed production usage and no security-response posture. Adopting it means inheriting the entire maintenance surface yourself.
- Does this bundle work with EventSauce 1.x?
- Unlikely without changes. The bundle predates EventSauce 1.0 (released in 2021), which introduced breaking changes to the message dispatcher, repository, and serializer interfaces. Expect it to pin an eventsauce/* version in the 0.x range. Check the exact constraint in composer.json and whether the DI wiring survives a bump before relying on it.
- Does the bundle ship a message repository implementation or only interfaces?
- The technical evaluation flags this as unverified, so inspect the service definitions before assuming anything. Thin bundles of this kind typically wire interfaces to implementations rather than shipping full persistence code. Plan on still owning the Doctrine DBAL or Eloquent message repository yourself.
- Is the message dispatcher bound synchronously or through Symfony Messenger?
- The evaluation lists this as an open question you must answer by reading the service definitions. If dispatch is asynchronous, dual-write correctness between the event store and projection dispatch becomes the key failure mode. Confirm the retry and at-least-once delivery story before trusting it unexamined.
- Does the bundle support event upcasting and snapshotting?
- This is unverified, and a 2019-era serializer and upcaster may not match current EventSauce upcasting ergonomics. Event schema durability is the highest-blast-radius artifact in an event-sourced system, so confirm how schema versions are tracked. Also check whether snapshotting is wired and whether any rebuild command for projections exists.
- Is there a test harness for aggregate unit tests, such as EventSauce TestUtilities?
- The evaluation does not identify any integration with EventSauce\EventSourcing\TestUtilities in the bundle. In practice you would add that harness yourself when writing aggregate tests. Because the bundle is Symfony-bound, any test tooling it provides would not plug into Laravel's testing conventions anyway.