- What is andrey-helldar/laravel-ide-facades-helper used for?
- It is a development-time tool that generates a PHPDoc stub file, typically _ide_helper_facades.php, annotating Laravel facades with @method and @see tags. IDEs like PhpStorm index that file so facade calls and static calls autocomplete correctly. It removes the spurious method-not-found warnings facades normally produce. It adds no runtime code to your application.
- Does laravel-ide-facades-helper support Laravel 10, 11 and 12?
- That is unlikely. The repository is archived and the last release was January 2022, when the package targeted Laravel 8 and 9. Its composer constraints almost certainly stop short of Laravel 10, 11 and 12 and PHP 8.2 through 8.4. Expect a dependency-resolution failure on a current application rather than a clean install.
- How do I install laravel-ide-facades-helper?
- The intended flow is composer require --dev andrey-helldar/laravel-ide-facades-helper, then run php artisan ide-facades-helper:generate to write the stub file. You can optionally publish the config to extend or exclude facades. On modern Laravel versions the require step is likely to fail platform checks. Because the package is archived, there is no upstream to report issues to.
- Is it a replacement for barryvdh/laravel-ide-helper?
- No, and in practice it is redundant. barryvdh/laravel-ide-helper already emits facade @method annotations as part of ide-helper:generate, and it is actively maintained. This package only covers the facade-annotation slice. Most teams gain nothing by adding it alongside a working ide-helper setup.
- Can I run it alongside barryvdh/laravel-ide-helper?
- You can, but it creates two sources of truth for the same annotations. Duplicate facade hints are a common cause of ambiguous or incorrect resolution in PhpStorm. If a project-specific or custom facade is genuinely missing from ide-helper output, the cleaner fix is extending that package, not installing a second generator.
- How do I exclude facades or change the output path?
- The package ships a publishable configuration file with options for the output path and a list of excluded facades. Publish it with the standard vendor:publish command and edit the facade list to match what you want documented. Re-run the generate command afterwards so the stub file reflects the new settings.
- Which IDEs read the generated facade stubs?
- The output is plain PHPDoc, so PhpStorm and other IntelliJ-based IDEs index it natively, which is the primary target. LSP-based editors such as Intelephense generally pick up a root-level helper file as well. Static analysers like PHPStan or Larastan with the Laravel extension usually resolve facades through their own mechanisms, so verify the generated format actually satisfies your toolchain.
- Is laravel-ide-facades-helper still maintained?
- No. The GitHub repository is archived and the last tagged release was 2022-01-18. Abandonment here is a fact rather than a risk: there is no patch cadence to track and no security-response path, though the exposure is minimal for a dev-only tool. Adoption is also very low, so edge cases across editor and framework combinations are unlikely to have been shaken out.
- What happens if I install it with --ignore-platform-reqs?
- Forcing it past Composer's checks typically yields a generator that runs but produces partial stubs. The facade map and reflection logic were written against roughly Laravel 8 and 9, so newer framework facades and accessor patterns will be missing. Incomplete autocomplete is worse than none, because developers trust it. Treat a forced install as a stop signal.
- Does it affect production performance or runtime?
- No. It registers a single Artisan command and writes one PHPDoc file at the project root; it sits on no request path and holds no state. Removal is a composer remove --dev plus deleting the generated file. The real consideration is ownership and maintenance, not runtime overhead.