- Is th3mouk/eventstore-bundle a Laravel package?
- No. It is a Symfony bundle that ships a DI extension and service definitions for an event store, with no Laravel service provider, facade, or publishable config. If your application is Laravel, treat this repository as reference code rather than a candidate Composer dependency.
- What does EventStoreBundle actually do?
- It wires an event store into the Symfony container so you can append domain events, load aggregates by replaying their stream, and build projections from the same event history. The functional surface is small: append events, read streams, and subscribe by polling. Most of the value is configuration and service wiring rather than domain logic.
- Can I install th3mouk/eventstore-bundle in a Laravel app with Composer?
- You can run composer require, but nothing will register it because there is no Laravel auto-discovery or service provider. Expect conflicts on the Guzzle major version, the PHP version floor, and Symfony component constraints as well. Adding it to a production Laravel composer.json is not recommended.
- Which PHP and Symfony versions does EventStoreBundle support?
- The bundle targets older Symfony releases where its bundle kernel and extension API still exist, and it predates PHP 8 support. Guzzle 7 is not supported. Check the composer.json constraints before planning anything, and assume a fork is required for modern runtimes.
- Does this bundle work with current EventStoreDB versions?
- It talks to EventStore's legacy HTTP/AtomPub interface through a Guzzle client. Modern EventStoreDB has de-emphasized HTTP in favour of gRPC, so even a successful integration commits you to a deprecated transport. If you are greenfield, gRPC should be the target regardless of this package.
- How is the underlying storage adapter configured?
- Configuration goes through the bundle's Symfony extension, which registers the event store services and the HTTP client used for persistence. There is no Laravel-style publishable config file with dotenv overrides. Credentials, endpoints, and content negotiation are set through container parameters.
- Is th3mouk/eventstore-bundle still maintained?
- No. The upstream repository is archived, with roughly five stars and zero dependents, so there are no releases, no PHP 8 work, and no security response. A dependency with no maintainer and no community to catch regressions is a risk-register entry, not a routine install.
- What are the alternatives to this bundle for event sourcing in PHP and Laravel?
- For Laravel, spatie/laravel-event-sourcing gives you aggregates, projectors, and reactors with a supported service provider. For framework-agnostic PHP, EventSauce and Prooph are established options, and a gRPC-based EventStoreDB client covers the transport layer. Any of these is a better bet than adopting an archived HTTP-only bundle.
- Does the bundle handle retries or idempotency when appending events?
- The client is essentially raw Guzzle calls, so retry, backoff, and idempotency on append are your responsibility. Duplicate-event risk is a domain correctness problem, not a plumbing detail. Design an explicit deduplication or expected-version strategy before any domain code touches the store.
- Should I fork the bundle or build my own event store client?
- If you already run an HTTP EventStore deployment you must interoperate with, lift the small client classes into an internal adapter behind an interface you own. For greenfield work, start from a maintained gRPC client or an event-sourcing framework and reimplement only the HTTP glue if HTTP is genuinely mandated. Either way, run a one-day spike against your target EventStoreDB version before committing.