Phpflo Bundle Laravel Package

Getting Started

First reality check: this is a Symfony bundle, not a Laravel package. It ships a Symfony Bundle class, a DI extension, and YAML config — there is no ServiceProvider, no facade, and no publishable config. Laravel will not auto-discover it. The v1.1.2 release (dependency cleanup only — see below) does nothing to change that. Given 4 stars, 0 dependents, and a package that sat dormant from February 2017 until this maintenance bump, treat the bundle itself as a reference implementation and expect to consume phpflo/phpflo (the core library) directly unless you have a specific reason not to.

Minimal steps if you still want to evaluate it:

1. composer require phpflo/phpflo — start with the core library, not the bundle.
2. Read the bundle's DependencyInjection/ extension class to see what it wires up (typically a Graph/Network factory and a component registry). That's the entire value the bundle adds on top of core.
3. If you want the bundle's service graph in Laravel, port those definitions into a ServiceProvider manually — do not try to instantiate the Symfony bundle.
4. Build a tiny flow in a tinker session or a test:

$graph = new \PhpFlo\Graph();
$graph->addNode('reader', 'ReadFile');   // component name from phpflo/phpflo
$graph->addNode('counter', 'CountLines');
$graph->addEdge('reader', 'out', 'counter', 'in');

$network = new \PhpFlo\Network($graph);
$network->run();                          // synchronous, blocking

First real use case: a graph-shaped data pipeline — file/stream ingestion, fan-out/fan-in transforms, or multi-stage ETL where Illuminate\Pipeline feels too linear. If your processing is a straight line of steps, stop here and use native Illuminate\Pipeline.

Implementation Patterns

Skip the bundle, wrap the core. The most maintainable Laravel integration is a thin package of your own: composer require phpflo/phpflo, then define a FlowServiceProvider that binds Graph and Network as scoped singletons and registers your custom components in a registry array.

Graph definition lives in code, not YAML. The bundle's YAML component registration is Symfony-specific and won't travel. Define graphs fluently in a dedicated class:

final class SalesReportFlow
{
    public function __construct(private ComponentRegistry $registry) {}

    public function graph(): Graph
    {
        $graph = new Graph();
        $graph->addNode('source', 'ReadCsv', ['path' => storage_path('app/sales.csv')]);
        $graph->addNode('map', 'MapRows');
        $graph->addNode('sink', 'WriteJson');
        $graph->addEdge('source', 'out', 'map', 'in');
        $graph->addEdge('map', 'out', 'sink', 'in');
        return $graph;
    }
}

Run flows in queue jobs or artisan commands, not in HTTP requests. Network::run() is blocking and synchronous. A RunFlow job per execution keeps web requests fast and gives you retries/backoff for free:

class RunFlow implements ShouldQueue
{
    public function handle(NetworkFactory $factory): void
    {
        $factory->make(SalesReportFlow::class)->run();
    }
}

Components as container-resolved services. Register each PhpFlo\Component subclass in a small registry or Laravel container alias mapping 'ReadCsv' => ReadCsvComponent::class. This is the one place where manually copying the Symfony bundle's extension logic is worth the effort — it keeps component construction lazy and injectable.

Two integration styles:

• Library-style — build a Graph, hand it to Network, run it. Good for batch/CLI pipelines.
• Message-style — components emit out-port packets and you attach a listener that forwards to a job or broadcast event. Good for reactive/incremental processing.

Testing: build minimal graphs (Source -> Transform -> Sink) and assert on collected output packets rather than asserting on Network internals. Components are plain classes — unit test them independently of the graph.

Gotchas and Tips

• No Laravel support out of the box. No service provider, no config, no auto-discovery — v1.1.2 does not change this. Anything you get working in Laravel is your own glue code; budget for it.
• Age and PHP compatibility. Core code dates to 2017, but v1.1.2 finally dropped the old php-utilities dependency and tidied file headers. That removes one common source of composer require conflicts, so try a normal install on your target PHP 8.x first. If you still hit constraint errors, pin phpflo/phpflo, use --ignore-platform-reqs, or fork — but expect less friction than before this release.
• A maintenance bump is not a revival. One release containing two dependency/cleanup commits is housekeeping, not a roadmap. There is still no Laravel support, no test-suite signalling, no published BC policy. Don't upgrade your risk assessment from "vendored dependency" to "maintained upstream" on this basis.
• Stateful components and Octane. Components and networks hold state per run. Never register Network as a singleton across requests under Octane or in long-lived queue workers — use scoped/bind semantics and rebuild per execution.
• Blocking execution. Network::run() blocks until the graph completes or stalls. A malformed graph with a disconnected out-port can silently deadlock or finish with no output. Always include a timeout/watchdog or a maximum-packet component.
• Port-name mismatches are the #1 debugging pain. Errors from addEdge on wrong port names can be quiet. Enable phpflo's logger (Psr\Log compatible) and add a temporary var_dump/log component between nodes to inspect packets.
• Packets are plain arrays/values, not DTOs. No type safety across edges; document the shape expected by each component or you'll chase runtime shape errors.
• Extending: the useful seams are custom Component subclasses, custom graphs, and the bundle's component-registration config (which you'll reimplement). The .fbp DSL loader exists but is unmaintained — prefer programmatic graphs.
• Community risk. Still ~0 dependents and no maintainer presence you can rely on for bug fixes. Vendor or fork phpflo/phpflo if this becomes load-bearing, and keep an exit plan to a maintained dataflow library or hand-rolled Illuminate\Pipeline + jobs.
• When not to use it: linear transformations, simple queued chains, or anything achievable with pipelines, jobs, and events. Reach for phpflo only when the graph topology itself (branching, fan-in, cycles) is the model you need.