Weave Code
Phpflo Bundle Laravel Package
phpflo/phpflo-bundle
Symfony bundle integrating phpflo/phpflo, the PHP flow-based programming (FBP) library. It helps wire components into dataflow networks inside Symfony apps, letting you define and run modular, event-driven processing pipelines with familiar FBP concepts. Small package with limited adoption, so revie...
phpflo/phpflo-bundle integrates the phpflo/phpflo flow-based programming library with Symfony. It lets you build and run FBP networks inside a Symfony application, exposing components, ports, and networks through the service container so flows can be configured and wired with standard dependency injection.
- Symfony DI integration for phpflo components and networks
- Configure flows and component wiring via services/configuration
- Reusable FBP components registered as container services
- Run flow-based networks within Symfony applications and console commands
Frequently asked questions about Phpflo Bundle
- What does phpflo/phpflo-bundle do?
- It is a thin Symfony bundle that integrates the phpflo/phpflo flow-based programming runtime. It registers components with the service container, loads graph definitions from configuration, and exposes a runner, usually as a console command. The actual dataflow engine lives in the core phpflo/phpflo library, so the bundle mostly handles wiring and configuration.
- Does phpflo/phpflo-bundle work with Laravel?
- No. It is a Symfony bundle with no Laravel ServiceProvider, no publishable config, and no facade, so Laravel package auto-discovery will not register it. Installing it in a Laravel app contributes essentially nothing beyond pulling in Symfony dependencies. If you want flow-based programming in Laravel, depend on phpflo/phpflo directly and bind the flow factory as a singleton yourself.
- How do I install phpflo/phpflo-bundle?
- You would normally require it with Composer and then register the bundle manually in config/bundles.php for Symfony 4 or later, or in AppKernel for legacy Symfony. There is no Symfony Flex recipe, so auto-registration will not happen. Be prepared for dependency resolution failures on modern Symfony or PHP versions because the last release dates to 2017.
- Which Symfony and PHP versions does phpflo/phpflo-bundle support?
- The bundle was last released in February 2017 and almost certainly constrains symfony/framework-bundle to the 2.7 or 3.0 era and PHP to 5.6 or 7.0. Modern Symfony 5, 6, or 7 and PHP 8.x will likely conflict at the Composer solver level rather than at runtime. Run composer why-not to confirm before planning any integration work.
- Is phpflo/phpflo-bundle compatible with PHP 8?
- Not without patching. Code from that era commonly breaks on removed functions like each, curly-brace string offsets, dynamic property deprecations, implicit nullable parameters, and Symfony DependencyInjection API changes. The bundle itself is small enough that a fork could be patched, but the core phpflo/phpflo library is the bigger unknown. Budget time for a compatibility audit and a test suite.
- What are the alternatives to phpflo/phpflo-bundle in Laravel?
- For queue or job workflows, use Laravel's built-in queue system or Horizon rather than a flow runtime. For genuine graph-shaped, componentized processing, depend on phpflo/phpflo directly and write roughly 100 lines of container wiring and an artisan command. That gives you the same capability with one less abandoned dependency and no Symfony bundle layer.
- Is phpflo/phpflo-bundle still maintained?
- There has been no release since February 2017, and the project shows 4 stars, 0 dependents, a single maintainer, and no visible security policy or CI. That is a high technical risk profile with a clear bus-factor problem. Treat it as an abandoned integration layer rather than a supported package, and plan an exit or fork strategy before adopting it.
- What are the production risks of using phpflo/phpflo-bundle?
- The main risks are Composer resolution failures on modern stacks, PHP 8 incompatibilities, and the absence of downstream users to serve as a de facto compatibility test. Flow-based programming also assumes a long-lived process holding a graph in memory, which means either rebuilding the graph per request or running a daemon such as RoadRunner, Swoole, or ReactPHP. That operational commitment exists independently of the bundle.
- How would I test a flow built with phpflo/phpflo-bundle?
- The package ships no test suite you can rely on, so you would need to write your own coverage for graph loading, component registration, and message flow. Unit-test individual components by feeding messages into input ports and asserting on output ports, then add an integration test that boots the container and runs a small graph end to end. If you fork the bundle, add those tests to the fork so future Symfony or PHP upgrades can be validated.
- Should I use the bundle or phpflo/phpflo directly?
- In most cases, use phpflo/phpflo directly. The bundle is the least valuable part of the stack and the most likely to break, since its only job is container wiring and graph configuration that you can reproduce in a small service class or console command. Only consider the bundle if you are on a legacy Symfony LTS and its config-driven graph registration saves meaningful work.
Weaver
How can I help you explore Laravel packages today?