- Is landingi/event-store-bundle a Laravel package?
- No. The package name, its *-bundle convention, and Landingi's Symfony-based stack all indicate a Symfony bundle, so there is no Laravel service provider, no package discovery, and no Laravel-style config publishing. You can still install it with Composer, but you would be consuming the underlying event-store library directly and hand-wiring its services, configuration, and Doctrine connections into Laravel's container. Treat it as a bespoke adapter project rather than a dependency add.
- When should I use an event store instead of a simple audit log table?
- Use it only when you genuinely need event sourcing: audit-grade history, temporal queries, replayable read models, or multiple projections over the same facts. If the requirement is an audit log plus a few notifications, a table with Eloquent observers and queued listeners is cheaper and safer to operate. Event sourcing is a one-way door for your domain model, so the real decision is whether to adopt event sourcing at all, not which library to pick.
- How do I install and register landingi/event-store-bundle in a Laravel application?
- Composer require is trivial, but runtime integration is the actual work. Expect to write a Laravel service provider that binds the store's interfaces, translate Symfony tree config into config/*.php, and bridge DBAL or Doctrine connections if the store does not speak Eloquent. A good practice is to define your own domain-facing interface and adapt Landingi's classes behind it, so your domain code is not coupled to a vendor package with no public API stability guarantee.
- Which Laravel and PHP versions does landingi/event-store-bundle support?
- There is no documented Laravel support matrix, because the bundle targets Symfony. Laravel already pulls in Symfony components, so the most likely immediate blocker is a conflict between the bundle's pinned symfony/* ranges and the framework's constraints during composer update. Inspect composer.json before anything else for PHP version, Symfony ranges, Doctrine DBAL, and PDO driver requirements, and expect to negotiate versions or pin the package.
- Does this event store work with Eloquent models and Laravel migrations?
- Unlikely by design. Event stores bypass the ORM, so your read side will be hand-built or projection-table based rather than Eloquent-native end to end. You will probably manage the event store schema with raw migrations or DBAL schema tools instead of Laravel's Eloquent-oriented migration conventions. If your team expects Eloquent models throughout, this package is a poor fit.
- How does the event store enforce optimistic concurrency when appending events?
- The concurrency contract is undocumented in the package description, so you need to read the code. A typical implementation checks an expected stream version on append and rejects or retries on conflict, but you must confirm whether that is enforced, what exception or result you get on a conflict, and whether retries are your responsibility. Concurrency semantics are expensive to discover late, so verify them in the spike rather than in production.
- Is there a framework-agnostic core library I can use without Symfony's kernel?
- This is one of the key unknowns and the first thing to check in the repository. Symfony bundles normally rely on a DI extension class, compiler passes, and tag-based service discovery, none of which exist in Laravel. If a framework-agnostic core sits beneath the bundle, you can instantiate it yourself in a service provider; if the logic is entangled with the kernel, integrating it becomes significantly more expensive.
- What database and schema does the Landingi event store require?
- Expect Doctrine DBAL against MySQL or PostgreSQL, with Postgres generally preferred for JSONB storage and cleaner append concurrency. Verify the exact requirements in composer.json, including the DBAL version and PDO drivers, before you plan your infrastructure. You also need to know the on-disk or database schema and whether it is versioned with a migration path for event schema evolution, since stored events are effectively permanent.
- How can I safely test this package before committing to it?
- Run a timeboxed two-day spike: clone the repo, read composer.json and the DI extension, then attempt composer require in a throwaway Laravel app. The success criterion is simple and binary: append an event and read it back. If the repository has a test suite, run it as an acceptance gate, and treat failure at this stage as a signal to stop rather than push through.
- What are the alternatives to landingi/event-store-bundle for Laravel event sourcing?
- Spatie's laravel-event-sourcing is the Laravel-native option and comes with documentation, community usage, and Eloquent-friendly projections. Prooph or other framework-agnostic stores are options if you want a library that does not assume a Symfony kernel. Landingi's bundle has effectively zero external validation, no dependents, and a single-line description, and since Landingi is a SaaS vendor publishing for its own use, there is no roadmap obligation to outside consumers. Confirm a maintainer of record before you build on it.