Weave Code
State Bundle Laravel Package
survos/state-bundle
Survos State Bundle provides a lightweight foundation for modeling and managing states in Symfony applications, with configurable transitions and entity integration to reduce boilerplate for workflows and status tracking.
Add some tools managing state machines using the Symfony Workflow Component
Frequently asked questions about State Bundle
- What does survos/state-bundle actually do?
- It adds declarative state management to Symfony applications by letting you attach a state to any Doctrine entity with a single PHP attribute. The bundle then registers the corresponding Symfony Workflow definition, transitions, guards, and listeners behind the scenes, so you avoid hand-written workflow configuration. Typical uses are order lifecycles, publication or moderation status, and any entity that moves through defined stages.
- How do I install survos/state-bundle with Composer?
- Run composer require survos/state-bundle and make sure the bundle is registered in config/bundles.php, which Symfony Flex usually handles automatically. After that, clear the cache so workflow definitions are rebuilt from your entity attributes. Check the package's composer.json constraints for PHP and symfony/* before installing into an existing application.
- Is survos/state-bundle compatible with Laravel?
- No, this is a Symfony bundle built on Symfony Workflow and Doctrine ORM, not a Laravel package with a service provider or illuminate/* dependencies. Installing it in a Laravel application would not give you framework-native integration, because Laravel has no Symfony Workflow component wired into its container by default. For Laravel you should use a dedicated state machine package or model transitions with events and database columns.
- Which Symfony and PHP versions does the bundle support?
- The README excerpt does not publish a support matrix, so the authoritative answer is the php and symfony/* constraints in composer.json. Confirm those constraints cover the versions running in your production environment before adopting, and treat a gap of more than one Symfony major as a stop signal. If you need a formal policy on adopting new Symfony releases, ask the maintainer directly.
- How do I define states and transitions on a Doctrine entity?
- You annotate the entity class with the bundle's state attribute and declare the allowed states and transitions alongside it, rather than writing workflow YAML by hand. The bundle reads that metadata and registers a matching Symfony Workflow definition at compile time. Because the definitions are generated, you should clear or warm the cache after changing attributes so the workflow reflects the new states.
- Can I block a transition with a guard or react to one with a listener?
- Yes, guard and listener hooks are part of the bundle's core design, so you can validate a transition with minimal custom code. A guard that returns false prevents the transition from being applied, and listeners let you run side effects after a successful transition. If the built-in hooks are not enough, the bundle is documented as extensible so you can override defaults or plug into existing workflow definitions.
- How are state changes persisted, and does the bundle ship migrations?
- The bundle is Doctrine-friendly and persists state changes alongside your entity lifecycle, so the state is stored on the entity and saved on flush like any other mapped field. Schema changes normally come from your own entity mapping rather than bundle-owned tables. Verify in the repository whether any additional tables or migrations are shipped, and if they are, confirm they are additive-only and reversible before running them against production data.
- How do I test workflows built with this bundle?
- Use PHPUnit or your existing Symfony test suite, boot the kernel so workflow definitions are compiled, and assert that applying a transition moves the entity to the expected place while guards block the invalid ones. Persisting and re-fetching the entity in a test database confirms the state survives the Doctrine lifecycle. If your CI enforces PHPStan or Larastan-style baselines, check the package's type hints first, since incomplete docblocks can fail a strict gate.
- What changed in version 1.7, and is it safe to upgrade?
- The supplied release notes for 1.7 are empty, so there is no evidence of what changed beyond the version number. Semver convention says a 1.x bump should be non-breaking, but that is an assumption rather than proof. Review the changelog, the composer.json diff for PHP and symfony/* constraints, and any config or schema diff before scheduling the upgrade.
- Is the bundle actively maintained, and what are the alternatives?
- It appears to be a single-maintainer package with best-effort releases, which carries the usual abandonment and unpatched-CVE risk, so ask about the security disclosure process and support commitment. If that risk is unacceptable, the alternatives are configuring Symfony Workflow directly, using WinzouStateMachineBundle, or, on Laravel, reaching for a native state machine package. Pinning a known-good version and wrapping the bundle behind your own service interface limits the blast radius if maintenance stops.
Weaver
How can I help you explore Laravel packages today?