Action Laravel Package

Product Decisions This Supports

• Whether to standardize business logic at all. The real decision this package surfaces is architectural, not procurement: do we adopt a single-purpose "action" convention (one class = one business operation, called identically from HTTP, queue, CLI, and tests) or keep logic in controllers, models, and jobs? The package is a vehicle for that convention, not the convention itself.
• Build vs. buy vs. borrow. Everything here is an abstract base class, a run() entry point, a data() helper, and a make:action Artisan generator. For a mid-level Laravel engineer, replicating this internally is roughly a day of work plus a test. That makes "buy" a very low-stakes commitment but also a weak one — the decision to consider is borrow the idea, own the code versus take the dependency and inherit its maintenance posture.
• Pilot scope and sequencing. Because switching cost is trivial in both directions, this is a good candidate for a time-boxed pilot on exactly one high-value workflow (checkout, onboarding, provisioning, report generation) before any broader refactor is funded. Define the success metric up front: reduced controller size, duplicated logic eliminated across entry points, and test coverage on the extracted workflow.
• Reuse-across-entry-points roadmap bets. The queue story (ShouldQueue + dispatch()) and method injection into handle() mean the same operation can run synchronously from a controller and asynchronously from a worker without two implementations. This directly supports roadmap items like "run this operation in the background," "expose this via API and console," or "retry failed operations," and it is the clearest product justification for the pattern.
• Consistency and onboarding decisions. A generator-backed convention gives new hires and contractors a prescribed place to put logic and a prescribed shape for it. That is a legitimate team-scaling argument, but it is only real if the team actually enforces it in review — the package cannot enforce anything.
• Dependency-risk budgeting. With 0 stars, 0 dependents, a single maintainer, and a personal email as the security contact, this should be classified as an internal utility rather than an approved vendor dependency. The PM decision is whether to accept a small, forkable, unmaintained dependency or simply absorb it — and to record the exit plan either way.

When to Consider This Package

Consider it when:

• The team has already agreed to use an action/service pattern and wants zero-config scaffolding plus a shared base class rather than debating a bespoke one.
• Your stack matches the package's actual constraints — PHP 8.2+ and Laravel 9–13 — with the composer.json verified directly rather than inferred from the README.
• The motivating pain is concrete and measurable: the same workflow duplicated across controllers, queued jobs, and console commands, or controllers that have become untestable.
• You are comfortable extending the base class yourself for cross-cutting concerns (validation, authorization, DB::transaction(), logging, events) and comfortable forking or inlining it if upstream goes quiet.
• You want a low-ceremony pilot: install in an afternoon, prove the convention on one workflow, and keep the option to walk away.

Look elsewhere (or build internally) when:

• You already have a service layer, command bus, or DDD convention. This would introduce a competing convention rather than reduce duplication — a net negative for comprehension.
• You need validation, authorization, middleware, transactions, event hooks, or action chaining out of the box. None of that ships here. In particular, once an action is callable from a job or command, controller-level validation and authorization no longer protect it; that is an architectural gap you must close in code, and it is the most likely source of a real incident.
• The application is straightforward CRUD. The abstraction overhead exceeds the DRY benefit.
• You operate under procurement, security review, or long-term vendor-confidence requirements. Zero adoption and a single maintainer will not clear most of those gates.
• You are on Laravel 8 or older. Support was dropped in 2.0.0; do not assume backward compatibility from the package name or prior notes.

One flagged design risk to resolve before adoption: the data() helper returns all constructor properties as an array, which makes Model::create($this->data()) extremely convenient — and a silent over-posting hazard. Adding a property later (e.g. userId, isAdmin) changes what gets persisted without touching the handle() body. If you adopt, mandate explicit payload arrays or tightly scoped $fillable in review, and treat this as a standing code-review rule rather than a footnote.

How to Pitch It (Stakeholders)

For executives: This is a small, MIT-licensed utility that gives the team a consistent home for business logic — one class per operation, callable identically from a web request, a background job, or a command. The business payoff is fewer bloated controllers, logic that is written once and reused across entry points, and workflows that are easier to test and therefore safer to change. The catch is credibility of the dependency: it has essentially zero community adoption and a single maintainer, so it should be positioned as an internal convention we are borrowing, not a strategic platform bet. Recommendation: approve a short, time-boxed pilot on one high-value workflow with an explicit success metric, and pre-approve the fallback of absorbing the ~one-file abstraction internally. Cost of exit is negligible; cost of over-committing is a stalled refactor.

For engineering: The package supplies an abstract Action base class, a static/instance run() that resolves handle() through the container (so services are injected automatically, sync and in queue workers alike), a data() helper, and a make:action generator writing to app/Actions. Queue support comes from implementing ShouldQueue with the standard Queueable/InteractsWithQueue/SerializesModels traits — do not add Dispatchable, the base class already provides dispatch() and the trait will conflict. Treat the following as our own responsibility, not the package's: input validation, authorization, transactions, events, and idempotency, all of which matter more once actions are invoked from non-HTTP contexts. Two guardrails for review — never feed data() straight into create() without pinning $fillable, and pin the version with a committed lockfile since a 2.0-style revamp already happened once at near-zero adoption. Start with one genuinely complex workflow; if the abstraction doesn't pay for itself there, it won't pay for itself anywhere.