Laravel Action Laravel Package

Product Decisions This Supports

• Build vs. buy for a business-logic layer. This package supplies the "Action" convention (single-purpose classes that encapsulate one operation) instead of a bespoke internal abstraction. The decision it informs: standardize on an existing, small-footprint pattern rather than have each squad invent its own service/handler layer.
• Architecture roadmap. Adopting the Action pattern now makes it cheap to later move work from synchronous request handling to queued jobs without rewriting business logic, because the unit of work is already isolated.
• Delivery predictability. A shared convention for "one class = one operation" reduces review variance and makes onboarding cheaper — a PM-visible lever on cycle time rather than a purely technical choice.
• Feature shaping / use cases. Good fit for order and payment processing, onboarding and approval workflows, third-party integrations, webhook handlers, and background jobs where a discrete, testable unit of work is the natural boundary.
• Release 2.3.0 specifically: a compatibility release, not a capability release. It adds Laravel 13 support (illuminate constraints now include ^13.0), PHPUnit 12 compatibility, and Pest 4 support; it updates phpunit.xml.dist, standardizes CI on Laravel 12 + PHP 8.4/8.3, and bumps dev-only dependencies (larastan, phpstan plugins, collision). No new features, no deprecations, no breaking changes. The PM-relevant read: the maintainer is actively tracking the framework's release train, which lowers the "will this be abandoned on the next Laravel major?" risk. It is a minor version bump — treat as a routine dependency update, not a migration project.

When to Consider This Package

Consider it when:

• The team already leans toward the Action pattern, or fat controllers / god-services are a recurring review complaint.
• You are on a currently supported Laravel line (this release explicitly covers through Laravel 13) and PHP 8.3/8.4.
• You want a thin convention with a small surface area rather than a framework-within-a-framework.
• Your test stack is PHPUnit 11/12 or Pest 3/4 — 2.3.0 removes the test-tooling friction that usually blocks adoption.
• The blast radius of the dependency matters more than breadth of features: a small package is easier to fork or replace if it stalls.

Look elsewhere when:

• You need workflow orchestration, sagas, compensation/rollback, or multi-step pipeline composition — that is a different class of tool.
• You are pursuing heavy DDD/CQRS/event-sourcing architecture where a lightweight action helper adds little.
• You require commercial support, an SLA, or multi-vendor governance; verify maintainer count and release cadence against your dependency policy before committing.
• A larger-community alternative already covers your needs — the switching cost between action-pattern packages is low, so pick on maintenance signals and fit, not on features alone.
• Your platform is pinned to an older Laravel major; the widened ^13.0 constraint means you should confirm your installed illuminate version still resolves in the same composer update.

Adoption guardrails: pin the version, run the 2.3.0 bump as a standalone PR (dev-dependency and CI changes only), and have engineering verify the phpunit.xml.dist / PHPUnit 12 changes do not conflict with your existing test configuration before merging.

How to Pitch It (Stakeholders)

For executives (one paragraph): This is a small, low-cost structural convention that makes business logic easier to test, review, and later move to background processing. The 2.3.0 release is maintenance only — it keeps the package current with Laravel 13, PHP 8.4, PHPUnit 12, and Pest 4, with no breaking changes and no migration work. The signal that matters is maintenance health: the maintainer is shipping compatibility updates promptly, which is the main risk with small open-source dependencies. Recommendation: approve as an internal convention, pin the version, and revisit at the next Laravel major.

For engineering (the asks): Treat 2.3.0 as a routine minor bump — constraint widening on illuminate, test-tooling bumps, CI standardization. No API changes to design around. Confirm resolution under your Composer constraints, fold the phpunit.xml.dist changes into your own test config rather than overwriting it, and align your CI matrix with the Laravel 12 / PHP 8.3–8.4 baseline the maintainer now tests against. Worth a short spike to confirm the pattern fits your domain before standardizing across squads.

For product (the trade-off): The upside is consistency and cheaper refactors later; the cost is one more dependency and a convention the team must actually follow. The risk is maintainer concentration, mitigated by the package's small surface area — replacing it is inexpensive if it stalls.