- How do I install laravel-flows with Composer?
- Install it with Composer via composer require juststeveking/laravel-flows. There are no migrations to publish and configuration is minimal, so setup is essentially the Composer install plus optional Artisan scaffolding for generating flow classes. Because version 1.0.4 is a patch release carrying behavior-affecting changes to transaction semantics and validation, plan and regression-test it as a feature release. Review the diff of PR #5 before it goes anywhere near production.
- Which Laravel and PHP versions does laravel-flows support?
- The package is Composer-installable and framework-native, but the supported PHP and Laravel majors are not spelled out in the package overview. Check the composer.json constraints directly and confirm they match your application's PHP and Laravel versions before committing. Resolving that constraint question should be one of the first steps in any pilot.
- Do I need migrations or configuration to use laravel-flows?
- No migrations are required and configuration is minimal, which is why a contained pilot is a matter of days rather than a sprint. Steps are single-purpose classes resolved from Laravel's service container, so you express behavior in code you already review in pull requests. Artisan scaffolding is available to generate flows and keep their structure consistent across teams.
- How does laravel-flows handle database transactions and nested flows?
- Transaction boundaries landed in 1.0.4, but the package does not document whether they are scoped per flow, per step, or opt-in, so verify this in the source before relying on it. Nested flows are the sharp edge: Laravel silently converts nested transactions into savepoints, which can leave a flow partially committed while still reporting success. Decide up front how you handle side effects that cannot be rolled back, such as mail, HTTP calls, and dispatched jobs.
- Can laravel-flows run inside queued jobs and handle retries?
- Flows can be invoked from controllers, queued jobs, and Artisan commands, so adoption can be incremental inside your existing service and action layers. How transactional execution interacts with job retries, partial failure, and multiple database connections is not documented, so test those paths explicitly in a queued context. Keep non-idempotent side effects out of steps that may be retried unless you add your own guard.
- How does step-level validation work in laravel-flows?
- Release 1.0.4 adds step-boundary validation, but the declaration contract, the exception thrown, and whether failure occurs before or after any writes are not documented in the overview. Introducing validation can reject payloads that previously passed, and without characterization tests around current service behavior that surfaces in production rather than CI. Write characterization tests first, then tighten step validation incrementally.
- Do the laravel-flows generics give runtime type safety?
- The generics added in 1.0.4 are PHPDoc-level only and deliver real value for PHPStan and Psalm, but they are not runtime enforcement. Treat them as reviewer and static-analysis ergonomics rather than a guarantee at execution time. Confirm they pass your static-analysis baseline without new suppressions before rolling them out broadly.
- How do I test a flow built with laravel-flows?
- Because a flow is a dedicated class composed of single-purpose, container-resolved steps, you can unit test each step and cover the flow end to end through its single public entry point. That is far easier to test than a multi-step process buried in a controller or job. Before upgrading, add characterization tests around existing behavior so validation and transaction changes show up in CI instead of production.
- Is laravel-flows production-ready given its single maintainer?
- It is pre-2.0, maintained by a single author, with zero dependents and no enterprise SLA, so scope it as a contained, reversible bet rather than a system of record. Record that risk as an explicitly accepted decision instead of leaving it implicit. Pin versions, review each release diff, and keep the flow layer thin enough that removing the package is not a rewrite.
- How does laravel-flows compare to Temporal or a BPM engine?
- Laravel Flows keeps workflows as code in version control rather than configuration in a visual builder, which suits teams that value testability and pull-request review over orchestration dashboards. It introduces no new runtime, deployment unit, persistence layer, or operational surface, unlike Temporal or a SaaS BPM engine. With 1.0.4's transaction boundaries and step validation it becomes a credible in-app workflow primitive and a genuine build-versus-buy line item for contained processes. Reach for Temporal or a BPM engine when you need cross-service orchestration, durable timers, and an operations console.