- What does wulfheart/laravel-actions-ide-helper actually do?
- It is a dev-only code generation package that reads your Laravel Actions v2 classes and writes IDE helper stub files describing each action's methods and signatures. PhpStorm and VS Code language servers then autocomplete methods such as handle, rules, authorize, and asController, along with action constructor and parameter types. It replaces the hand-maintained @mixin and @method docblocks teams typically write by hand. It does nothing at runtime.
- How do I install laravel-actions-ide-helper?
- Run composer require --dev wulfheart/laravel-actions-ide-helper, then run php artisan ide-helper:actions to generate the helper files. In the common case there is no config file to publish and no service provider to register. Most teams treat it as a small ticket of roughly half a day including verifying autocompletion in their editor.
- Which Laravel, PHP, and Laravel Actions versions are supported?
- The package requires Laravel 10 through 13.x, PHP 8.1 or newer, and lorisleiva/laravel-actions v2.3 or higher. Composer will block installation if those constraints are not satisfied in your project. If you are still on an older Laravel or Actions v1, it is not a fit.
- Do I need to register a service provider or publish a config file?
- No. Integration is a single require-dev line plus the php artisan ide-helper:actions command. There is no publish step, no configuration file, and no provider registration required in the standard setup. That keeps the setup footprint minimal compared with most Laravel packages.
- Does it work with Laravel Actions v1 or plain controllers?
- No. The generator is written specifically against the Laravel Actions v2 method surface, so v1 actions, controllers, or service classes produce nothing useful. The fit is binary: if your codebase uses Actions v2 as a first-class pattern you get recurring value, and if it does not, the package adds no benefit. There is no partial adoption story.
- Will this package affect my production application or its performance?
- No. It is installed as a require-dev dependency and only emits static stub files for your editor, with no middleware, facade, service provider, or runtime interception in the request lifecycle. Deployments that install with --no-dev never load it. The blast radius on production code is effectively zero.
- How often should I regenerate the action helper files, and can I run it in CI?
- Regenerate after you add or change action method signatures, since the stubs are a build artifact that goes stale otherwise. Some teams commit the generated output so editors and CI agree, while others gitignore it and regenerate locally, and the package does not enforce either. If you want it in CI, add the Artisan command to a job that installs dev dependencies.
- The README says YOLO-mode. Is this package still maintained?
- It is explicitly community-powered: the maintainer no longer uses Laravel Actions, offers no guarantees, merges fixes without testing them, and is openly looking for someone to take over. Recent Laravel 13 compatibility came from drive-by contributors rather than the original author. With low star counts and no ecosystem dependents, it is reasonable for local developer convenience but risky if you need support commitments.
- Does it conflict with lorisleiva/lody or phpdocumentor/reflection-docblock?
- It can, which is the most likely reason an integration attempt stalls. The release history is dominated by dependency bumps for lorisleiva/lody and phpdocumentor/reflection, including a targeted compatibility fix against reflection-docblock 5.4.0. Run composer why-not before committing if your static analysis or documentation toolchain already pins those libraries.
- What happens if Laravel Actions ships a v3, and what are the alternatives?
- Because the generator is coupled to Actions' internal method surface, a v3 that reshapes the action contract could silently produce wrong or stale signatures rather than failing loudly. The fallback is hand-written @method docblocks or a stub committed to the repository, which is acceptable but reintroduces manual maintenance. Given the package's support model, you should be comfortable fixing breakage yourself before adopting it.