- How do I install michael-rubel/laravel-enhanced-pipeline?
- Install it with Composer using composer require michael-rubel/laravel-enhanced-pipeline. The package is MIT licensed and registers itself through Laravel package auto-discovery, so no manual service provider registration is required. You then opt in per call site rather than changing anything globally.
- Which Laravel and PHP versions does laravel-enhanced-pipeline support?
- Version 5.0.0 adds Laravel 12 compatibility and PHP 8.4 test coverage, which strongly implies a minimum-version bump from the 4.x line. If you are on Laravel 10 or PHP 8.1 you will likely need to stay on 4.x, which will not receive Laravel 12 support. Always read the composer.json constraints for the exact release you install instead of assuming 5.x applies to your codebase.
- What does this package add over Laravel's built-in Pipeline?
- It is a thin, additive wrapper around Illuminate\Pipeline\Pipeline that wraps a pipeline in a database transaction, fires events around execution, and adds fluent helpers for chaining invokable pipes. The value is collapsing hand-rolled transaction and event boilerplate into a declarative API for multi-step workflows like checkout, onboarding, or import processing. It polishes an existing Laravel pattern rather than introducing a new abstraction, so migration cost is low.
- Do pipeline steps roll back if one of them fails?
- Yes for database writes: the pipeline runs inside a transaction, so a failing pipe triggers a rollback of the SQL changes made by earlier pipes. Rollback does not cover non-database side effects such as queued jobs, outbound HTTP calls, cache writes, or filesystem changes. Design each pipe so the irreversible work happens after the transaction commits.
- What happens to queued jobs or API calls dispatched inside a pipe when the pipeline fails?
- They are not rolled back. The transaction boundary only protects database statements, so a job pushed or an HTTP request sent by an earlier pipe will still exist after a later pipe throws. The usual mitigation is to dispatch jobs with afterCommit or to collect side effects inside the pipeline and execute them once the transaction succeeds.
- How do the pipeline events work, and can a listener abort the run?
- The package dispatches events around pipeline execution so you can hook logging, metrics, or notifications without polluting pipe classes. Because listeners execute as part of the run, an exception thrown inside a listener can abort the pipeline mid-transaction, so keep them defensive. Check the README for the exact event taxonomy and whether each event fires inside or outside the transaction boundary before relying on it.
- Can I nest laravel-enhanced-pipeline inside an existing database transaction?
- Yes, but be aware that nested transactions in Laravel are implemented as savepoints. A rollback at the inner level only rewinds to the savepoint, while the outer transaction can still commit or roll back independently. If your application already opens a transaction around the call site, test the failure path explicitly rather than assuming the whole unit of work is atomic.
- Does this package replace Laravel's default Pipeline container binding?
- Adoption is opt-in per call site, either by swapping the container binding or by using the package's facade, so existing app()->make(Pipeline::class) usage keeps working. Confirm this against the version you install, since the docs do not spell out every binding detail. Keeping it opt-in makes it easy to trial on a single workflow before wider rollout.
- Is 5.0.0 a breaking change from 4.x and how should I upgrade?
- Treat 5.0.0 as a semver major: the changelog mentions Laravel 12 support and PHP 8.4 testing, which points to dropped minimum constraints, but it does not enumerate API changes. Read the diff between 4.0.1 and 5.0.0 for signature changes, renamed methods, or behavior differences that touch your call sites. Pin the version in composer.json and run your test suite before deploying.
- Is the package actively maintained and well tested enough for production?
- The project has a single maintainer and a small user base, so bus factor is the main concern rather than code quality. Positively, 5.0.0 shipped Laravel 12 support through a community pull request and CI now runs PHP 8.4, showing the project tracks the framework and accepts contributions. Edge-case coverage for transaction and event behavior is not documented, so review the test suite and add your own integration tests around failure paths.