Laravel Actions Laravel Package

Product Decisions This Supports

• Build vs. buy on architecture: laravel-actions is not a feature you ship — it's a convention layer. The real decision is whether to standardize an internal "one class = one task" pattern, and whether to encode that pattern in a maintained package (MIT, ~2.9k stars, active through Laravel 13) or hand-roll the convention in an internal base class. Adopting the package buys documentation, make:action scaffolding, and a community of prior art at near-zero licensing cost.
• Consolidating duplicated entry points: The core value proposition is that one action class can run as an object (::run), invokable controller, queued job, event listener, and artisan command. This directly supports the roadmap decision "should this be a job or a controller?" being deferred — you can start synchronous and promote the same class to a queued job without rewriting business logic. That's a measurable reduction in rework when a feature graduates from MVP to scale.
• Feature delivery velocity and test surface: Because actions are plain invokable objects, they are trivially unit-testable and mockable (Action::mock()), and the package ships a PHPStan extension (v2.11.0) plus IDE autocomplete fixes. This supports a roadmap commitment to raising static-analysis levels or shortening the path from feature spec to tested unit.
• Onboarding and code-location decisions: The convention answers "where does this logic live?" — a recurring PM-visible cost in code review latency and cross-team contribution friction. New hires and cross-team contributors get a predictable target (app/Actions), which matters if the roadmap includes scaling the engineering team or opening the codebase to more squads.
• Platform upgrade decisions: Recent releases track Laravel 12 (v2.9.0) and Laravel 13 (v2.10.0), plus Octane-safety work (v2.1.5) and PHP 8.4 deprecation fixes (v2.8.6). This means the adoption decision can be bundled with a framework-upgrade initiative rather than run as a standalone risk.
• Specific use cases worth scoping: transactional actions that need both HTTP and CLI surfaces (admin tooling), event-driven side effects (v2.1.1 added queued listeners; v2.10.2 fixed ShouldDispatchAfterCommit), idempotent/unique queued work (ShouldBeUnique support, debounced jobs in v2.13.0), and unified attribute handling with validation (WithAttributes).

When to Consider This Package

Consider adoption when:

• The application has, or is heading toward, multiple invocation surfaces for the same business operation (API endpoint + scheduled command + queued job + event listener). That duplication is where the package pays for itself.
• Your team is standardizing conventions across squads and needs a documented, opinionated answer to "where does this logic go?" — the package's docs (laravelactions.com) and make:action scaffolding reduce the need for internal architecture docs.
• You are on Laravel 11–13 (PHP 8.2+) and can absorb the Lody dependency introduced in v2.2.0; actions outside the App namespace are resolvable, which matters for modular/multi-package codebases.
• You value testability and static analysis as roadmap commitments — the mocking helpers and PHPStan extension are concrete, non-marketing wins.
• You want a small, reversible architectural bet: MIT-licensed, no runtime service, no data lock-in. Worst case, action classes remain plain PHP objects and the trait can be stripped.

Look elsewhere when:

• The codebase is small or short-lived (a single-surface CRUD app, internal tooling with a fixed scope). A plain service class or Laravel's native invokable controller gets you 80% of the benefit with zero abstraction.
• The team is unfamiliar with or resistant to the pattern. This package is a convention whose value is entirely social; unenforced, it becomes a second, parallel way of doing things and increases cognitive load rather than reducing it.
• You need strict, stable API guarantees across a multi-year horizon. Versioning is disciplined but semver-minor releases have historically carried behavior fixes (v2.10.0 dropped Laravel 10, v2.2.0 introduced Lody); you'll want to pin versions and budget upgrade time.
• Debugging transparency is a hard requirement — heavy use of magic decorators (job decorators, asJob argument prepending, unified attributes) can make stack traces and queue payloads less obvious than an explicit Job class, which slows incident response.
• You already have a mature domain layer (DDD-style command bus, CQRS handlers) where actions would be a redundant fourth abstraction.
• Note the dependents: 0 signal in the package metadata — almost certainly a data-collection artifact rather than a genuine absence of consumers, but treat it as an unverified assumption and do your own reference-checking before citing ecosystem adoption as a justification.

How to Pitch It (Stakeholders)

For executives (one paragraph): Laravel Actions is a free, MIT-licensed convention that lets one class describe one business capability and run it as an API endpoint, a background job, an event listener, or a CLI command without rewriting it. The business case is rework avoidance: features that start as simple endpoints frequently need to become queued or scheduled later, and today that means a second implementation and a second set of tests. It also gives us a single answer to "where does this code live," which shortens code review and onboarding as the team grows. Risk is low — it's a pattern, not a platform, with no data lock-in, a permissive license, and active maintenance through Laravel 13. Cost is adoption effort, not procurement.

For engineering leadership: The pitch is consistency plus testability, not novelty. We get a documented, opinionated structure for business logic, scaffolding via make:action, first-class mocking for unit tests, a PHPStan extension, and Octane-safe internals. We should adopt it as an explicit, enforced standard in a bounded area (new feature work) and measure it: time-to-first-commit on new features, count of duplicated job/controller pairs eliminated, and static-analysis level over two quarters. Mitigations: pin the version, gate upgrades behind our Laravel upgrade cadence, and keep the escape hatch explicit — if the abstraction ever fights us, action classes remain plain PHP and the trait is removable.

For the engineering team: This is a tool for deferring an irreversible decision. You write the business logic once in handle(), and the asController / asJob / asListener / asCommand methods are thin adapters. You can ship synchronous today and promote to a queued job with a decorator, without touching handle(). It comes with test mocking and a PHPStan extension. The tradeoff is honest: it's an abstraction, decorators add indirection in stack traces, and the pattern only works if we actually follow it — so we adopt it as a standard in new code, not as an optional extra.