- Is kphoen/doctrine-state-machine-bundle a Laravel package?
- No. It is a Symfony bundle that integrates the Doctrine finite state machine library with Doctrine ORM entities, registered through the Symfony bundle kernel and driven by Doctrine lifecycle events. It depends on Symfony's dependency injection container and the Symfony event dispatcher, not on Laravel's service providers, Eloquent, or Laravel events. Treat it as a Symfony 2/3-era component, not something you drop into a Laravel app.
- Can I use this state machine bundle with Laravel and Eloquent models?
- Not directly. Eloquent models are not Doctrine entities, so the bundle's metadata listener and transition subscriber have nothing to attach to. The only workable path is a Doctrine-backed bounded context using something like laravel-doctrine/orm, plus a hand-written service provider that wires the Doctrine EventManager and a symfony/event-dispatcher shim. That bridge is typically more code than the workflow logic it enables.
- How do you install and configure kphoen/doctrine-state-machine-bundle?
- In a Symfony 2/3 application you require it with Composer, register the bundle in AppKernel, and declare your machines in YAML, XML, or PHP configuration. Guards, actions, and transition callbacks are then bound to container services. There is no Laravel service provider, no config publish command, and no Artisan tooling shipped with the package.
- Does this bundle support PHP 8 and modern Symfony or Laravel versions?
- There is no evidence it does. The package is explicitly marked deprecated, its last release was 2016-08-17, and its dependency graph predates Symfony 4/5 and Doctrine ORM 2.10. PHP 8.1+ compatibility is unverified and likely broken, so expect composer why-not conflicts almost immediately in a modern host application.
- Where are state machine definitions stored — annotations or YAML?
- Definitions are split: machines, transitions, guards, and callbacks live in Symfony bundle configuration (YAML, XML, or PHP), while the state field itself is mapped on the Doctrine entity via docblock annotations. Docblock annotation mapping is no longer supported on modern Doctrine, which only accepts attributes. Either way, workflow shape is partly invisible to grep and awkward to review in a pull request.
- What alternatives should Laravel developers use for state machines and workflows?
- Build on Eloquent rather than fighting it: a backed enum for states, a transition table, a can() guard check, and a single transitionTo() mutator that writes the state and emits a domain event in the same transaction. A focused in-house implementation is roughly 200 to 400 lines and stays fully testable. If you prefer a package, Laravel-oriented options such as spatie/laravel-model-states map to Eloquent far more naturally than this Symfony bundle.
- How do you test a Doctrine state machine integration in a Laravel application?
- You would need a Doctrine EntityManager with the correct metadata driver in your test bootstrap, then unit test guards and actions as plain services and integration test transitions against a throwaway database. Most failures show up as silently missing transitions rather than exceptions, so assertions must verify the persisted state field, not just that a call returned. A Laravel-native replacement is far easier to test: assert can() results, call transitionTo(), and use Event::fake() to confirm the domain event fired.
- What are the production risks of adopting this bundle?
- The package is deprecated and abandoned: no maintainer, no security response path, no PHP 8.x compatibility work, and a tiny install base. A mis-ordered Doctrine listener fails as a missing transition, causing silent state drift rather than a loud error. The version ceiling will also block Symfony and Doctrine upgrades in the host application. For new work the composite assessment is a do-not-adopt signal.
- Does this bundle provide an audit log of state transitions?
- No. It dispatches transition events through the Symfony event dispatcher, which you could listen to, but it does not persist an immutable history of transitions. If you need a compliance-grade audit trail, that record-keeping has to be built yourself. That requirement alone usually pushes teams toward a custom implementation where the audit write happens in the same transaction as the state change.
- What is the migration path if we already depend on this bundle?
- Port the pattern rather than the artifact: extract a states enum, an explicit transition table, guard checks, and one transitionTo() method that persists state and emits a domain event atomically. Keep the existing tests as the specification for the new implementation. The design extraction is typically two to three days of work and removes a vendor fork you would otherwise own forever. Decide up front who owns that fork and what the exit trigger is, such as a PHP upgrade, a security finding, or the first production incident.