Weave Code
Pipeline Laravel Package
zaengle/pipeline
Zaengle Pipeline is a lightweight Laravel package for building and running data pipelines. Chain reusable pipe classes to transform, validate, or filter data with a clean, expressive API, making complex multi-step workflows easier to organize and test.
A wrapper around the Laravel Pipeline class with a few additional niceties
Frequently asked questions about Pipeline
- What does zaengle/pipeline do that Laravel's built-in Pipeline doesn't?
- It is a thin wrapper around Laravel's Pipeline class that adds a few conveniences for defining and running reusable pipe classes. The underlying pattern is unchanged: each stage receives the payload plus a next closure and returns the value passed to the following stage. The value is mostly ergonomic, giving you a cleaner and more expressive API for chaining stages, rather than introducing new runtime behavior. If you only need a one-off chain of closures, Laravel's native Pipeline is already sufficient.
- How do I install zaengle/pipeline?
- Install it with Composer as zaengle/pipeline. It is a Composer-only integration with no external services, credentials, or schema migrations required for the core pipeline API. Package auto-discovery handles what little bootstrapping exists, so no manual service provider registration is expected. Installation takes hours, not sprints; the real effort is decomposing your existing business logic into discrete stages.
- Which Laravel and PHP versions does zaengle/pipeline v6 support?
- The v6.0.0 release notes cite support for Laravel 13 and PHP 8.4 alongside an expanded CI matrix. The changelog does not explicitly enumerate dropped versions, so check the composer.json constraints and CI matrix before assuming it installs cleanly on your stack. Teams on Laravel 11 or 12 with PHP 8.2 or 8.3 should verify compatibility first and may need to stay pinned to ^5.0.
- Is upgrading zaengle/pipeline from 5.x to 6.0 a breaking change?
- By convention a major version bump signals dropped support for older framework or PHP versions, and this release does raise the floor to Laravel 13 and PHP 8.4. The release notes describe the change as additive, but they do not list removals, deprecations, or internal signature changes. Treat the missing breaking-changes section as a documentation gap rather than proof of a smooth upgrade, and diff composer.json and the CI configuration yourself before adopting it.
- Do I need to publish config files or run migrations to use zaengle/pipeline?
- No. The package is a thin orchestration layer, so there is no schema, no external service, and no credentials involved in the core pipeline API. Auto-discovery means you do not register a provider by hand either. Any configuration is opt-in and publishing it is not a prerequisite for getting started.
- How do I write and unit test a pipe class with zaengle/pipeline?
- Each pipe is a plain invokable class, so you can unit test it in isolation by passing a payload and a stub next closure. That keeps domain logic decoupled from the framework and makes every stage independently testable. Whole pipelines can be exercised end to end by asserting the final payload after the chain runs. Prefer focused tests on individual pipes over one large happy-path pipeline assertion.
- Can zaengle/pipeline replace Laravel queues or a workflow engine?
- No. The package describes how a unit of work is decomposed into ordered stages; it provides no durable execution, retry semantics, or scheduling. Queues and the scheduler decide when and where work runs, and pipelines are complementary to them rather than a substitute. Teams frequently assume a pipeline package solves orchestration problems it was never designed to handle.
- What are the alternatives to zaengle/pipeline?
- Laravel's built-in Pipeline is the closest alternative and is often enough if you only need to chain closures. league/pipeline offers a framework-agnostic implementation of the same chain-of-responsibility pattern. Hand-rolled closures or extracted service classes also work well when the flow is short or unlikely to grow. Because all of these rely on plain invokable stages, switching between them is a relatively low-cost exercise.
- Is zaengle/pipeline actively maintained, and what is the bus factor risk?
- It is a small, single-agency package, so maintenance is concentrated in a small number of maintainers. The v6 release being primarily a Laravel and PHP compatibility bump is a positive sign that it is being kept alive, though it also suggests low feature velocity. For a utility of this size neither point is disqualifying, but both argue against letting the package become deeply embedded in your architecture.
- What is the exit cost if we later remove zaengle/pipeline?
- Because every pipe is a plain invokable class, the blast radius is small: you can swap the package's runner for plain closures or Laravel's native Pipeline and keep your stage classes. The practical cost is the number of call sites that reference the package, not the volume of code inside the pipes. Also keep payload shapes explicit, since stages sharing a mutable payload tend to grow implicit contracts that are harder to reason about than the original linear code.
Weaver
How can I help you explore Laravel packages today?