Installation

Laractions is a library, not a scaffold. There is no config file to publish, nothing to register in a service provider and no base class of yours to change. One Composer command and you can write the first action.

composer require edulazaro/laractions

EduLazaro\Laractions\LaractionsServiceProvider is auto discovered. It registers the two Artisan commands and declares the tracing migration as publishable. That is the whole footprint.

Requirements

Nothing else. The package leans on the framework you already have: the container resolves actions, the validator checks their arguments, the queue runs them.

Where actions live

Actions go in app/Actions, and model scoped actions in app/Actions/{Model}. That is where make:action writes them and where list:actions looks, but nothing enforces it: an action is an ordinary class, so it can live anywhere PSR-4 can reach. If you move them somewhere else, list:actions stops finding them, which is the only thing you lose.

Tracing

Tracing is the one feature with a database table behind it, and it is opt in twice over: the migration is not loaded automatically, and tracing has to be switched on per call with trace(). If you never call it, you never need the table.

php artisan vendor:publish --tag=laractions-migrations
php artisan migrate

That creates action_traces: nullable morphs for the actor and the target, the action class name, and a JSON column with the resolved parameters. See Actors and tracing for what gets written and when.

Queues

Running an action inline needs no setup. Dispatching one needs the queue you would set up for any Laravel job: a connection in config/queue.php and a worker consuming it.

php artisan queue:work --queue=default,emails

One detail worth knowing before you test anything asynchronous. With QUEUE_CONNECTION=sync, which is still the default in a fresh .env, dispatch() runs the action immediately in the same process. Everything works, but nothing is deferred, and a failure surfaces as an exception at the call site rather than as a failed job. It is a common source of "the delay is being ignored": a sync connection has nowhere to put a delay.