Product Decisions This Supports
- Build vs. buy for workflow/state-machine features. This package is a data point in a landscape scan for order lifecycles, approval chains, content publishing states, KYC/onboarding flows, and ticket status machines. Its conclusion is negative: it confirms the category exists but that this specific artifact fails as a buy candidate.
- Roadmap scoping: "workflow" as a first-class domain concept vs. status enums. A simple FSM (states, transitions, guards, events) is often enough for v1. Packages like this — minimal, transition-centric, no persistence opinions — are useful for calibrating how little machinery a first release actually needs before investing in a full workflow engine.
- Reference design, not a dependency. Because it's MIT and small, it's readable as a conceptual model: how to structure transition guards, how to fire events on state change, how to keep the state machine out of your entities. That informs our own design review even though we won't install it.
- Supply-chain and dependency governance. With 2 stars, 0 dependents, and an archived repository, this is a clean worked example for our package-adoption rubric — useful when we justify "we don't take dependencies under N stars / no release in 12 months / no maintainer response."
- Framework-fit triage. This is a Symfony2 bundle, not a Laravel package. Recording that explicitly prevents wasted spikes on "can we just drop this in?" — bundles rely on Symfony's DI container, bundle registration, and kernel lifecycle; they do not map onto Laravel's service providers without a shim.
When to Consider This Package
Adoption criteria — all of which it fails:
- Actively maintained. It is archived (read-only). No bug fixes, no security patches, no compatibility work.
- Supported platform. Symfony 2.x is end-of-life (2.8 support ended in 2018). Even the framework it targets is unsupported.
- Ecosystem validation. 2 stars and 0 dependents means essentially no production usage to learn from and no community to escalate to.
- Framework match. It is not a Laravel package. There is no path to adoption in a Laravel codebase without writing and owning a compatibility layer — at which point we have built it ourselves with extra steps.
The only defensible uses:
- You are already maintaining a legacy Symfony 2.x application, and the bundle is already vendored — in which case the decision was made years ago and this is a migration-liability note, not an adoption decision.
- You want to read the source (MIT permits forking) to borrow modeling ideas. Do not add it to
composer.json.
Where to look instead:
- Symfony: the native
symfony/workflow component — maintained, framework-supported, guarded transitions, marking stores, event dispatching.
- Laravel:
spatie/laravel-model-states for state machines on Eloquent models; symfony/workflow via a community bridge if the workflow semantics matter more than Eloquent integration; or plain PHP 8.1+ enums with explicit transition methods and guard clauses, which covers most v1 needs with zero dependencies.
- Build in-house if the state graph is small and domain-specific — the code is measured in dozens of lines and we retain full control of persistence and audit logging.
How to Pitch It (Stakeholders)
Recommendation: do not adopt. This is a Symfony2 bundle — not Laravel — and it is an archived repository targeting an end-of-life framework, with 2 GitHub stars and zero known dependents. Adopting it would mean owning an unmaintained dependency, writing our own compatibility layer to make it work outside Symfony, and accepting that no one will ever patch a security issue in it. The cost of ownership exceeds the cost of the feature it provides by a wide margin.
To executives: the workflow capability we're evaluating is real and worth building; this vendor is not a shortcut to it. Treat this as a completed evaluation with a "no" outcome, not an open option. Recommended path is either a maintained, actively-supported package or a small in-house implementation — both are lower-risk and, at this scale, comparable in effort.
To engineering: use it as a design reference only (guarded transitions, event-on-transition, keeping state logic out of entities). Budget a short spike to compare maintained alternatives — symfony/workflow for framework-agnostic semantics, spatie/laravel-model-states for Eloquent-native — against a plain enum-plus-guards implementation. Do not add it as a dependency, and note the framework mismatch explicitly so it doesn't resurface in future landscape scans.