Piper Laravel Package

Product Decisions This Supports

• Build vs. buy for pipeline/pipe-and-filter plumbing. Piper (transprime-research/piper) targets the "pass a payload through a sequence of callables" pattern that otherwise gets hand-rolled in service classes and controllers. The PM decision it informs is narrow but real: standardize this on a small dependency instead of letting three squads invent three different handle() chains.
• Major-version upgrade triage. 3.0.0 is a breaking release by semver convention, and the only substantive change visible in the notes is a raised floor (feat: set minimum php version to 7.4). That drives a concrete roadmap question: which of our services and CI images are still pinned below PHP 7.4, and what's the cost to lift them before we can take this upgrade. For most teams on Laravel 8/9+, this is a no-op; for any legacy monolith on 7.2/7.3, it's a blocking dependency.
• Maintenance-health signal, not a feature signal. The release is dominated by CI scaffolding (GitLab CI file created, renamed to ci.yml, a master merge) and one behavioral-sounding change ("Proxied piper call"). The PM takeaway is that this is a low-velocity, single-maintainer package where releases are often housekeeping. That argues for treating it as a convenience dependency, never a load-bearing architectural one.
• Not a roadmap driver. Nothing here changes user-facing capability, performance, or integration surface. Do not allocate roadmap capacity to this release beyond a routine composer update ticket and a compatibility check.

When to Consider This Package

Adopt when:

• You have genuinely repetitive multi-step transformation logic (validation → normalization → enrichment → persistence) and want a consistent, testable abstraction rather than nested conditionals.
• Your stack is confirmed at PHP 7.4+ — 3.0.0 makes this explicit, so verify your floor and your CI matrix before upgrading. Note that 7.4 itself is end-of-life; a "minimum 7.4" package tells you nothing about whether PHP 8.2/8.3 are actively tested, so smoke-test on your target runtime.
• You can absorb the cost of an unpinned, single-maintainer dependency — meaning the abstraction is thin enough to fork or vendor if it stalls.
• You are already on 2.x and the upgrade is a version bump, not a refactor. If you're on 2.2.0, read the 2.2.0→3.0.0 diff before merging; the changelog does not describe the breaking change beyond the PHP floor, and "Proxied piper call" is unexplained.

Look elsewhere when:

• You need a pipeline with first-class framework integration — Laravel's own Illuminate\Pipeline (or laravel/pipeline conventions) already covers most of this and ships with the framework you've already paid for. That is the default "buy" answer, and this package must beat it on ergonomics to justify itself.
• Your platform team requires documented support windows, security response SLAs, or multi-maintainer bus factor. This repo shows one contributor across all six PRs in this release.
• You're below PHP 7.4, or you cannot tolerate a changelog that omits breaking-change detail on a major bump.
• The need is one-off. A single three-step chain does not warrant a dependency; write the function.

How to Pitch It (Stakeholders)

For executives: This is a small, low-risk utility package, and the new 3.0.0 release is a maintenance release, not a capability release. Its practical impact is a compatibility gate: it now requires PHP 7.4 or newer, so the only decision it forces is confirming our runtime floor before we upgrade. There is no user-facing change, no cost, and no new vendor relationship — the package is free and open source, maintained by a single author, and confined to internal code-organization plumbing. Recommendation: approve a routine upgrade where we're already on PHP 7.4+, and do not treat it as strategic.

For engineering: 3.0.0 adds CI (GitLab CI, now ci.yml) and raises the minimum PHP version to 7.4; the changelog does not otherwise document what breaks, and "Proxied piper call" needs to be read in the diff before we bump. Two asks: (1) confirm we aren't taking this on a sub-7.4 image, and smoke-test on our actual production PHP version since 7.4 is EOL and 8.x coverage isn't evidenced; (2) before adopting, justify it against Illuminate\Pipeline, which we already have. If we do adopt, keep the surface thin — treat it as a forkable convenience layer, not core infrastructure, given the single-maintainer profile.