Weave Code
Process Bundle Laravel Package
cleverage/process-bundle
CleverAge ProcessBundle is a Symfony bundle for configuring series of tasks to run in order, making import and export workflows much easier to set up while supporting far more custom process needs. Compatible with stable Symfony and LTS releases, with a demo project available.
CleverAge/ProcessBundle is a Symfony bundle for configuring and orchestrating series of tasks that run against a given order or item. It simplifies building import/export pipelines while remaining flexible enough for any multi-step processing workflow, with configuration driven by Symfony's service container.
Designed for Symfony stable and LTS releases, it includes a demo project and full documentation.
- Configure task chains via YAML/service configuration
- Chain reusable processors into ordered processes
- Ideal for import/export and data transformation workflows
- Compatible with Symfony stable and LTS versions
- Open source under the MIT license
Frequently asked questions about Process Bundle
- What is cleverage/process-bundle used for?
- It is a Symfony bundle for configuring ordered series of tasks, composed of readers, splitters, transformers and writers, that import, export, transform and validate data. Because the chain is assembled through configuration rather than code, it handles import/export workflows but stays flexible enough for any multi-step process. Full documentation ships in docs/index.md and a working demo project is published separately.
- Can I use cleverage/process-bundle in a Laravel application?
- Yes, but with a caveat: it is a Symfony bundle, so Laravel hosts get no autoconfiguration and services must be bound and tagged explicitly in a service provider, or the ProcessManager constructed with an explicit checker array. The pipeline architecture itself is framework-agnostic, so readers, splitters, transformers and writers orchestrated via configuration port over cleanly. Treat Laravel support as a small manual shim rather than first-class integration, and budget a one-time wiring cost.
- How do I install and set up cleverage/process-bundle?
- Install it with Composer (composer require cleverage/process-bundle) and, on Symfony, enable the bundle in your bundle registration file; on Laravel you register the services yourself in a service provider. Pipelines are then defined through configuration, connecting readers and splitters to transformers and writers. The repository's docs/index.md is the reference for the available task and option configuration.
- Which Symfony versions does cleverage/process-bundle support?
- The README states compatibility with the current stable Symfony release and the latest Long-Term Support (LTS) version. The v5.3 release only adds an optional argument and no mandatory configuration surface, so staying on a recent v5.x is low risk. If Composer resolution fails after an upgrade, check the composer.json dependency declarations tracked in issue #190.
- How does the stop checker / cooperative cancellation in v5.3 work?
- Services implementing ProcessStopCheckerInterface, autoconfigured with the tag cleverage_process.stop_checker, are consumed through a new optional $stopCheckers argument on ProcessManager. Before each task executes, the manager asks them whether to stop; if any returns true the task is skipped and the process fails with a ProcessFailedException whose previous is the new ProcessStoppedException. It is a pre-task hook, not a mid-task interrupt, so no task is left half-written and a long-running transformer always finishes before the next check.
- How do I register a stop checker in Laravel without Symfony autoconfiguration?
- Implement ProcessStopCheckerInterface, then bind the service in a service provider with the tag cleverage_process.stop_checker and inject the tagged services into ProcessManager's $stopCheckers argument. If you are not going deep on the container, constructing the ProcessManager with an explicit array of checkers works just as well. Laravel has no autoconfiguration equivalent, so this wiring is required and is the one place the Symfony-first ergonomics need a shim.
- Will adding a stop checker break my existing ProcessFailedException handling?
- No. ProcessStoppedException is surfaced through getPrevious() on a ProcessFailedException rather than as a sibling type, so existing catch (ProcessFailedException) blocks still catch stopped processes and your error-strategy and alerting plumbing keeps working. Distinguishing a stop from a genuine failure requires inspecting getPrevious(), which is new work but not required work. With no checkers registered, default behavior is completely unchanged.
- What is the performance cost of enabling stop checkers?
- The check runs on every task boundary in every process, so a checker doing remote I/O such as HTTP, database or Redis calls will add that latency to every task. Keep checkers as cheap in-memory or locally cached reads. This per-task overhead is the primary performance risk introduced by v5.3.
- Is it safe to upgrade from v5.0 to v5.3?
- v5.3 itself contains no breaking changes: $stopCheckers is an optional argument with a default, so existing ProcessManager construction paths keep working. The real upgrade debt comes from v5.1, notably setAllowedTypes() option-type enforcement (#228) and the composer.json dependency declarations (#190), which are the most likely sources of post-upgrade breakage. If you instantiate ProcessManager positionally, audit the argument order for the new optional argument.
- How do I test a pipeline built with ProcessBundle?
- Because tasks are configured declaratively and failures funnel through a single ProcessFailedException, you can unit test readers, transformers and writers in isolation, then integration test the assembled process. A stub checker returning true lets you assert the stop path, including the ProcessStoppedException exposed via getPrevious(). The published demo project is a useful reference for wiring a testable setup.
Weaver
How can I help you explore Laravel packages today?