- Can I install fintem/workflow-logger-bundle in a Laravel application?
- Not as a real dependency. It is a Symfony bundle that registers itself through a Bundle class, a DependencyInjection extension, and compiler passes, and it hooks the symfony/workflow component; Laravel has service providers, not bundles. Making it resolve would mean pulling Symfony HttpKernel and DependencyInjection into a Laravel app as a shim that fights the framework container and buys you nothing. Treat the repository as reference source material, not something you add to composer.json.
- What does fintem/workflow-logger-bundle actually do?
- It adds a small event subscriber around Symfony Workflow transition events and writes a structured record for each one, capturing the workflow name, the from-place, the to-place, and the resulting marking. Records go out through a PSR-3 style logger, and the bundle also ships a Doctrine entity and repository so history can be persisted and queried. Because it auto-wires through bundle configuration, you do not have to register listeners by hand.
- Is fintem/workflow-logger-bundle still maintained?
- Effectively no. The last release was 2018-02-19, the project has one star and zero dependents, so there is no patch stream, no issue backlog to mine for known failure modes, and no field evidence of correctness at scale. Before copying any code, confirm whether the repository is archived and verify the license terms. Assume you would own any fork outright.
- Does fintem/workflow-logger-bundle work with Laravel 10 or 11?
- Almost certainly not. Laravel 10 and 11 pull Symfony 6.2 and 7.x components, while a 2018 bundle will declare constraints against Symfony 2.8, 3.x, or 4.x, so Composer resolution should be expected to fail outright. Even if a version matrix happens to overlap, the code path was never tested against a modern Symfony event dispatcher. Assume incompatibility until a spike proves otherwise.
- Should I force the install with --ignore-platform-reqs?
- No. That flag bypasses exactly the constraint checks that tell you the package was never validated against your Symfony component versions, which means shipping an unverified code path with no upstream fixes behind it. The cost of a one-to-three day port is almost certainly lower than the long-term risk of owning a forced, fragile dependency. Port the logic or replace it with a Laravel-native solution instead.
- How hard is it to port the workflow logger logic into Laravel?
- Plausibly one to three days for a senior engineer, because the package is small: an event subscriber on workflow.transition and workflow.guard delegating to a PSR-3 logger plus a Doctrine entity. In Laravel you would reimplement that as an event listener registered in a service provider, writing to a contract you define rather than the original 2018 log format. A half-day spike cloning the repo, reading the source, counting classes and LOC, and checking the license will settle port versus replace definitively.
- What should a workflow audit log record contain?
- Design the schema before writing any code: transition name, subject type and identifier, from-place, to-place, actor, timestamp, correlation or request ID, and a bounded context payload. Retention and immutability requirements differ sharply depending on whether the driver is debugging, compliance evidence, or analytics on state transitions. Locking that contract early stops you from inheriting a log format you cannot evolve. If you port the bundle, the ported code should write to your contract, not the original one.
- What are the alternatives to this bundle for a Laravel app?
- If you are not already committed to Symfony's Workflow component inside Laravel, a Laravel-native state machine such as spatie/laravel-model-states is the more sensible route, paired with an Eloquent-backed audit table or an event listener. If you do need Symfony Workflow semantics, you can still register the component in Laravel and write your own thin transition listener. Either way, the question to answer first is whether Symfony Workflow is a hard requirement or an inherited assumption.
- Where does the bundle store workflow logs and what sink should I use?
- The bundle writes through a PSR-3 logger and also provides a Doctrine entity and repository, so events can go to a file channel or a database table you can query. In Laravel you would swap Doctrine for Eloquent models and route output to a log channel, a database table, or an external SIEM. Decide the sink and who actually reads the logs before choosing an implementation, since that decision drives schema, retention, and indexing.
- How do I test a ported workflow logger in Laravel?
- Use Laravel's event fakes plus an in-memory SQLite database to assert that each transition writes a record with the correct workflow name, from-place, to-place, and context metadata. Add coverage for guard-rejected transitions, self-transitions that produce no movement, and actor or correlation ID propagation. If you are still evaluating the original, a two-hour read of the source will tell you which behaviours are worth reproducing and which are artefacts of the 2018 design.