Weave Code
Generator Laravel Package
php-stubs/generator
Generate PHP stub files from your codebase for better IDE autocomplete, static analysis, and documentation. php-stubs/generator scans sources and produces lightweight stubs suitable for packages and frameworks, helping consumers get accurate type hints without shipping full sources.
Generate stubs from any PHP code for IDE completion and static analysis.
Frequently asked questions about Generator
- How do I install php-stubs/generator in a Laravel project?
- Install it as a dev dependency with composer require --dev php-stubs/generator, which requires PHP 7.4 or newer and fits a Laravel 9+ runtime. You can then run the generate-stubs binary against one or more directories or files, optionally writing output with --out=/path/to/stubs.php. The programmatic API is just a few lines: instantiate StubsGenerator, run it over a Finder, and call Result::prettyPrint(). Keep it out of your production require block, since it is a build-time tool only.
- Does php-stubs/generator integrate with PHPStan or Psalm?
- Yes, but the generator only produces the stub files; you still have to register them with your analyzer via PHPStan stubFiles or scanFiles, or the equivalent Psalm configuration. Plan for tuning around false positives that stub-inherited declarations can introduce, since stubs restate what the source already says. If your only consumer is the IDE, the commitment is much cheaper than a full static-analysis pipeline. Decide up front which analyzer owns the stubs so you do not maintain two competing configurations.
- What PHP and Laravel versions does php-stubs/generator support?
- The package requires PHP 7.4 or newer, which aligns with Laravel 9 and later, and it has supported nikic/php-parser v5 since version 0.8.5. Support for new PHP syntax such as 8.4 and 8.5 has required explicit upstream patches, so parser coupling means brand-new language features can break generation until a release lands. It is a framework-agnostic tool rather than a Laravel package, so Laravel version support is effectively whatever your PHP runtime supports. Check the changelog before upgrading PHP in CI.
- Can php-stubs/generator create stubs for Laravel facades, Eloquent models, and macros?
- No. Facades, __call and __get magic, Eloquent attribute access, container-resolved contracts, and macros produce no static declarations to extract, so the generator cannot cover them. That gap belongs to laravel-ide-helper or explicit @method and @property annotations on your classes. Scope this tool to code that actually declares functions, classes, interfaces, traits, and constants. Promising facade or model coverage with it will only produce empty or misleading stubs.
- How is php-stubs/generator different from laravel-ide-helper?
- laravel-ide-helper relies on runtime reflection, so it boots your application and can only describe code it can safely load. php-stubs/generator works purely statically with nikic/php-parser, so it can stub legacy modules, vendored packages, and files that mix declarations with side effects without executing anything. That static approach is the strongest reason to adopt it. If you already run laravel-ide-helper, restrict this tool to non-Laravel and vendor code so both tools do not generate stubs for the same symbols.
- Does php-stubs/generator execute or autoload the code it scans?
- No. It parses source files with PHP-Parser and never autoloads, instantiates, or executes the target code, which is exactly why it can handle untrusted or side-effect-heavy files safely. This also keeps the supply-chain surface minimal for a dev dependency. The trade-off is that without reflection, inherited members, real constant values, and cross-file type relationships are resolved heuristically. Expect occasional correctness fixes around fully qualified names, declaration ordering, and duplicate constants.
- Should I commit generated stubs to version control or generate them in CI?
- Pick one and state it as policy. Committing stubs makes drift reviewable in pull requests, while generating them per CI run guarantees freshness but hides changes until analysis fails. Either way, assign an owner and a trigger such as a dependency bump, a release tag, or a scheduled job, because stale stubs silently diverge and your analyzer ends up validating against fiction. Document the regeneration command alongside the policy.
- Can php-stubs/generator stub vendored packages or WordPress-style code?
- Yes, that is its primary use case. It handles legacy modules, internal libraries published without PHPDoc, and files that mix function or class definitions with top-level side effects, which reflection-based tools cannot load safely. The output is a declaration-only stub file suitable for IDE completion. Keep in mind that untyped input produces untyped stubs, so the value is developer experience and visibility into missing types rather than new guarantees.
- Does php-stubs/generator add real type safety or fix missing type hints?
- No. Stubs only restate what the docblocks and signatures already declare, so untyped source produces untyped stubs and you gain no additional runtime or analysis-time guarantees. Position it as developer-experience tooling and technical-debt visibility, not as a correctness fix. If you need real typing, the work is annotating the source, not generating stubs around it. Expect to explain this distinction to reviewers who assume stubs equal safety.
- Is php-stubs/generator stable enough to depend on long term?
- Treat it as a utility you can fork or replace rather than a load-bearing dependency. It sits on a pre-1.0 version line with a modest star count, no listed dependents, and a small contributor set, so bus factor is a real consideration. On the positive side it is parser-only and never executes scanned code, so the security risk is low. Pin the version, keep generated stubs as a regenerable artifact, and be ready to swap in a different generator if maintenance stalls.
Weaver
How can I help you explore Laravel packages today?