Weave Code
Action Laravel Package
laraditz/action
A Laravel package for single-action classes that keep your app DRY. Each action handles one business operation, takes input via its constructor, resolves dependencies automatically through Laravel's container, and supports queueing.
Laravel Action provides a lightweight base class for encapsulating individual business operations as single-action classes, keeping your Laravel application DRY. Each action receives its input through the constructor and executes via a simple run() method, with services resolved automatically from Laravel's container.
- Artisan generator — scaffold new actions instantly with
make:action - Dual calling styles —
(new Action(...))->run()orAction::run(...) - Automatic dependency injection — type-hint services in
handle() - Queue support — implement
ShouldQueueto dispatch actions - Constructor input — explicit, readable, and easily testable parameters
Frequently asked questions about Action
- How do I install laraditz/action in a Laravel app?
- Run composer require laraditz/action. It is a single MIT-licensed Composer package with no transitive dependencies beyond Laravel core, no publishable config, and PSR-4 autoloading, so it works immediately after install. You only need PHP 8.2+ and Laravel 9 through 13. Lumen is also referenced as supported, though Lumen's reduced Artisan setup means you may need to register the generator command yourself.
- How does the make:action Artisan command work?
- Run php artisan make:action CreateNewPost and the package scaffolds a class into app/Actions by default. The generated file extends Laraditz\Action\Action and contains an empty handle() method for you to fill in. Each action is meant to encapsulate one business operation, with its input accepted through the constructor.
- What is the difference between instance style and static run() on an action?
- Instance style constructs the action first and then calls run(), for example (new CreateNewPost(title: 'Hello', body: 'World'))->run(). Static style passes the constructor arguments straight to run(), for example CreateNewPost::run(title: 'Hello', body: 'World'). The package documentation states both styles are equivalent, so pick one convention and apply it consistently across the codebase.
- How does dependency injection work inside an action's handle() method?
- Type-hint any service as a parameter on handle() and Laravel's container resolves it automatically when the action runs. For example, handle(Mailer $mailer) gives you a resolved mailer without any manual binding. Constructor arguments stay reserved for your own input data, which keeps the action's public API clear and testable.
- Can Laravel Action classes be queued as jobs?
- Yes. The package documents queue support: implement ShouldQueue on the action class to make it queueable and dispatch it like any other job. Because the action receives input via the constructor and resolves services through the container in handle(), the same class works synchronously in a controller and asynchronously on a queue worker. Check the README for the exact dispatch pattern before wiring it into production.
- What does the data() helper return and is it safe to use with Model::create()?
- data() returns all of the action's constructor properties as an associative array, so Post::create($this->data()) inserts every public constructor property. That is convenient but risky: adding a property such as $userId or $isAdmin later silently changes what gets persisted, which is a mass-assignment and over-posting hazard. Prefer explicit arrays or a strictly scoped $fillable on the model, and catch this in code review.
- Which Laravel and PHP versions does laraditz/action support?
- The current README declares PHP 8.2+ and Laravel 9 through 13. Version 2.0.0 was a full revamp of the Action class and dropped PHP 7 support, so older constraints will not resolve. Verify the actual composer.json constraint during evaluation rather than trusting README text or third-party notes.
- Where should validation and authorization live if logic moves into actions?
- The package provides no validation, authorization, transactions, or events of its own, and actions can be called from controllers, jobs, or console commands with any arguments. That means a controller's form request no longer guarantees validated input once the same action is invoked elsewhere. Relocate validation deliberately, either by validating inside handle() or by keeping a single entry point that always validates before running the action, and wrap multi-write actions in DB::transaction() inside the action itself.
- Is laraditz/action safe to use in production and is it actively maintained?
- It has very low adoption, a single maintainer, and no visible CI or security process, so assume no upstream support. The blast radius is small: it is an opt-in base class, not middleware or a service provider that rewrites routing or the container, and the code surface is roughly one file. Vendor-pin the version, commit your lockfile, and be ready to fork, which is realistically an afternoon of work. Treat any future 3.0 release as a migration event.
- Do I need this package or should I just write my own action classes?
- The package is essentially a one-file abstract base class with a handle() contract, a data() helper, a static run() method, and an Artisan generator. Its real value is standardisation and scaffolding ergonomics for teams that have already agreed on a single-purpose action pattern. If you already have a service layer, a DDD convention, or only simple CRUD, it adds a competing convention rather than reducing duplication, and you can own an equivalent abstraction yourself.
Weaver
How can I help you explore Laravel packages today?