- What is dragon-code/laravel-actions used for?
- It is a lightweight Laravel package for encapsulating business logic in reusable action classes instead of scattering it across controllers, commands, and jobs. A single action class can be executed as a controller, console command, event listener, queued job, or middleware, so the same behavior stays consistent across HTTP, CLI, and queue entry points. The goal is thinner controllers and models, less duplicated boilerplate, and workflows that are easier to test and maintain.
- How do I install dragon-code/laravel-actions?
- Install it with Composer using composer require dragon-code/laravel-actions. The package is Laravel-native with a service provider and publishable config, so package auto-discovery registers it without manual wiring. Publish the config file if you need to adjust defaults, then start declaring action classes. Before installing, confirm the Composer name against the repository you intend to use, because the two identifiers supplied for this package do not match.
- Which Laravel and PHP versions does it support?
- It is built as a Laravel-native package with a service provider, publishable config, and an artisan entry point, so it targets conventional modern Laravel releases. Exact PHP and Laravel constraints are declared in the package composer.json and on its Packagist page, and they change between releases, so check them before upgrading. This overview does not pin specific version numbers, so verify the requirement block rather than assuming compatibility with your application's Laravel version.
- How can one class run as a controller, command, job, listener, and middleware?
- You define the logic once inside an action class and the package supplies the thin adapters that expose it through each Laravel entry point. Routing to the action invokes it as a controller, the artisan entry point runs it from the CLI, and the same class can be dispatched as a job, registered as an event listener, or wrapped as middleware. Because every entry point calls the same class, fixes and behavior changes apply everywhere at once instead of being reimplemented per surface.
- Does it support Laravel dependency injection?
- Yes. Actions are resolved through Laravel's container, so you can type-hint services, repositories, or configuration in the constructor or method signature and let the framework inject them. That keeps action classes native to the framework rather than requiring a custom resolver or service locator. It also means standard Laravel container bindings and testing helpers work as expected.
- How do I test action classes?
- Action classes are ordinary PHP classes with injected dependencies, so you can instantiate or resolve them in a unit or feature test and assert on the result directly. Testing the action once covers every entry point, which is the main maintenance win over duplicating logic across controllers and commands. Use Laravel's container and fakes for dependencies, and add a thin feature test per entry point only where routing, console input, or queue dispatch behavior matters.
- Why does the Composer name not match the GitHub repository?
- The supplied Composer name is dragon-code/laravel-actions, while the linked repository is TheDragonCode/laravel-deploy-operations, and the documented feature set is closer to deployment operations than to the action-class overview. That suggests one of the two identifiers is wrong, but it is an inference, not a confirmation of the canonical Packagist name. Treat package identity as a gating item: verify the real Composer name, the release history, and the README before adding it to a project.
- Is it actively maintained and safe to depend on in production?
- Adoption evidence is thin: roughly 243 GitHub stars and zero dependents, meaning no downstream ecosystem has stress-tested it. Activity is real, and version 7.3.0 includes merged pull requests from an outside contributor, which is early evidence of a contributor base beyond the primary maintainer, but the bus factor remains effectively one person with occasional drive-by help. The MIT license means you can fork and own it if needed, but only adopt it if you are prepared to do that. Read it as unproven rather than broken.
- Do queued operations require a queue worker, and what else should I check before production?
- In 7.3.0 operations run as dispatched jobs, so the pipeline depends on a working queue worker and queue backend, and a stuck worker will stall a run. The queue job class is overridable for retry policy and observability, and the uniqueness lock duration is configurable so you can tune overlap prevention to your actual run time. Note that 7.3.0 also changes how the --isolated option detects overlap to match Laravel core presence semantics; it is an additive semver release but behaviorally observable, so read the diff before upgrading. The package does not replace a deployment platform: it has no zero-downtime symlink switching, release directory management, or built-in rollback.
- What are the alternatives to dragon-code/laravel-actions?
- For the action pattern itself, Laravel's invokable controllers, job classes, and artisan commands cover most cases, and other action-oriented packages exist if you want a fuller convention. If what you actually need is deployment orchestration, compare against Deployer, Envoyer, Forge, Vapor, or Kubernetes jobs, which provide release management rather than just ordered execution. On a non-Laravel stack, or a stack already standardized on one of those tools, this package is a redundant abstraction.