- What does digitalrisks/laravel-eventstore actually do?
- It is an event-sourcing persistence layer for Laravel that stores domain events in append-only streams and lets you rebuild aggregates by replaying those streams. Events live alongside your existing application data and are exposed through Laravel's service container, config, and migration conventions. It also gives you a full auditable history of every state change, plus snapshot support for aggregates with long streams. Think of it as domain persistence and replay tooling, not a general-purpose logging library.
- How do I install laravel-eventstore in a Laravel application?
- Install it with Composer using composer require digitalrisks/laravel-eventstore, which registers via package auto-discovery. Then publish the package config and migrations, run php artisan migrate, and configure your event store connection in the published config file. The real effort is not installation but domain modeling: defining aggregates, event classes, projectors, and read models. Plan your budget around that design work rather than the composer require step.
- Which PHP and Laravel versions does laravel-eventstore support?
- Supported PHP and Laravel constraints are declared in the package's composer.json for the release line you install, so check that file for the exact 8.4.x requirements before upgrading. The package tracks modern Laravel conventions such as auto-discovery, publishable config, and migrations. Since the project has shipped eight major versions, version constraints have moved over time, so verify requirements rather than assuming an old Laravel version works. Pin an explicit constraint such as ^8.4.1 instead of using a floating version.
- Does laravel-eventstore require a separate Event Store server such as EventStoreDB?
- The package follows Greg Young's event store model of append-only streams and event replay, and it persists those events in your application's relational database. That means a standard MySQL or Postgres connection is the storage backing, not an external EventStoreDB cluster. The connection-loss behavior introduced in 8.4.1 reinforces this, since it deals with database connection failures at write time. Confirm the storage expectations in the config and migrations after publishing them.
- How should I handle the ConnectionLostException change in laravel-eventstore 8.4.1?
- Version 8.4.1 changes connection-loss conditions to throw a ConnectionLostException instead of a plain Exception, which is non-breaking under semver but a silent behavior change for anyone catching broadly. Grep your event-store call sites for catch (\Exception) and catch (\Throwable), then insert a specific catch for ConnectionLostException before the generic handler and add bounded retry with backoff. Watch catch-block ordering, because a generic catch placed first makes the new type unreachable. Also update your global exception handler and error-reporting config so this type is classified as infrastructure failure and maps to a retryable 503 rather than a 500 in web paths.
- Do I need snapshots, and how do I rebuild an aggregate from its stored stream?
- Snapshots are optional but become important as an aggregate's stream grows, since replaying thousands of events on every load is expensive. The package supports persisting snapshots alongside events so you can rehydrate from the latest snapshot and replay only the events after it. Rebuilding is a matter of loading the stream for an aggregate identifier and applying events in order onto a fresh aggregate instance. Your replay tooling and projector design are the parts that need the most care, not the API itself.
- Is laravel-eventstore a good fit if I only need an audit log?
- Probably not. If your requirement is append-only logging of changes, a single database table plus a queued job will do the job with far less ceremony. This package earns its complexity when you actually need event replay, event-sourced aggregates, or read models projected from streams. Adopting it purely for an audit trail means paying the domain-modeling cost without using the benefits. Be honest about which of those two problems you have before installing it.
- How do I test event-sourced code built with laravel-eventstore?
- Test at two levels: unit-test aggregates by feeding events in and asserting the resulting state and the events recorded, and integration-test the store against a real database connection. The 8.4.1 exception change is worth an explicit test that simulates a dropped connection and asserts your retry and classification logic engages. Also assert catch-block ordering by verifying that the specific ConnectionLostException handler fires rather than the generic one. Run these tests in a non-production environment before bumping the dependency.
- What are the production concerns for laravel-eventstore at scale?
- Event volume growth is the main one: a single relational store will eventually need snapshotting, archival, and stream pruning strategies to stay fast. Queue-driven projectors and long-running consumers also need real handling for transient database failures, which is exactly what the new ConnectionLostException type is meant to signal. Confirm how partial writes are handled if a connection drops mid-append, since transactional guarantees there are not obviously documented. Budget for replay tooling and operational runbooks, not just the initial integration.
- How stable is laravel-eventstore, and how does it compare to spatie/laravel-event-sourcing?
- It has shipped eight major versions, so expect breaking changes to arrive at major boundaries rather than in patches; 8.4.1 is patch-level with no schema migration, no public API signature change, and no deprecations announced. The risk in that release is concentrated in exception-handling code and anything that pattern-matches on exception class strings, so confirm no other internal package pins the exact 8.4.0 version. Spatie's package is the more commonly cited alternative and offers a comparable event-sourcing feature set with heavier documentation. Evaluate both against your need for replay tooling, snapshotting, and long-term maintenance before committing.