Weave Code
Phpdoc Reader Laravel Package
php-di/phpdoc-reader
PhpDocReader parses @var and @param docblock types to resolve class names, supporting fully qualified, imported, relative, and aliased names with the same rules as PHP. Primitive types are ignored; only valid class names are returned. Used by PHP-DI.
Read @var and @param annotations in phpdoc blocks
Frequently asked questions about Phpdoc Reader
- How do I install php-di/phpdoc-reader with Composer?
- Run composer require php-di/phpdoc-reader and the library is ready to use immediately, with no service provider, config file or facade to publish. It has no framework coupling, so nothing needs registering in a Laravel application. You simply instantiate PhpDocReader and pass it ReflectionProperty or ReflectionParameter objects.
- Does php-di/phpdoc-reader work with Laravel's service container?
- Laravel's container already resolves typed constructor parameters through reflection, so this package only fills the gaps, such as untyped legacy parameters annotated with @param or properties you introspect for custom resolution. Wrap PhpDocReader behind your own interface and bind it in a service provider so the resolution logic stays swappable and testable. The package ships no Laravel integration of its own.
- Which PHP versions does php-di/phpdoc-reader support?
- Check the php constraint in composer.json and the GitHub Actions CI matrix before committing, because the last tagged release dates to October 2020. The repository does carry a CI badge, which is a positive signal that it is still exercised against newer runtimes. If you target PHP 8.3 or newer, run the suite on your own runtime rather than assuming compatibility.
- Does PhpDocReader handle union, nullable or generic types like ?Foo or array<Foo>?
- No. It is a narrow @var and @param type-token resolver, not a general PHPDoc parser, so generics, array shapes, union and intersection types are out of scope. Treat it strictly as a class-name inference helper for dependency injection. For richer type information, evaluate phpdocumentor/reflection-docblock, roave/better-reflection or symfony/property-info.
- What does PhpDocReader return for primitive types like @var string?
- Primitive and scalar types are ignored and the library returns null, so only resolvable class names come back. The same null result appears for arrays, unresolvable tokens and unreadable docblocks, and there is no diagnostic channel. Your calling code must handle null explicitly rather than expecting an exception.
- How does PhpDocReader resolve imported, aliased and relative class names?
- It applies the same name-resolution rules as PHP: fully qualified names starting with a backslash, imported names via use statements, relative names from the current namespace, and aliases created with use ... as. To do this it reads and tokenizes the declaring source file, so that file must exist and be readable. Generated or eval'd classes without a real source file will not resolve.
- What happens if opcache.save_comments is disabled?
- Docblocks are stripped at compile time, so every read returns null and the library degrades silently instead of raising an error. That makes it a genuine production risk in environments with aggressive opcache settings. Keep opcache.save_comments enabled in your ini baseline, or restrict docblock resolution to compile-time and build-time work.
- Is php-di/phpdoc-reader still maintained?
- It is a small single-responsibility library of roughly 300 lines under the MIT license with a single maintainer, and its last tagged release was in October 2020. Low churn is expected for a stable, narrowly scoped utility, and CI still runs against the codebase. The tiny surface means vendoring or forking it is cheap if you ever need a fix.
- How do I test code that uses PhpDocReader?
- Because the public API is essentially two methods on one class, you can wrap it behind your own interface and stub it in unit tests. Add integration tests with real fixture classes covering fully qualified, imported, relative and aliased annotations, plus null cases such as @var string. That setup also lets you verify behaviour for grouped use statements and modern PHP syntax on your target runtime.
- Should I use PhpDocReader instead of native reflection types?
- Use native reflection first: typed properties since PHP 7.4 and union and intersection types since PHP 8 cover most modern code without touching docblocks. Reach for PhpDocReader only for untyped legacy code annotated with @var or @param, which is exactly the autowiring gap it was built to fill for PHP-DI. Avoid calling it at request time and prefer compile-time or cached introspection instead.
Weaver
How can I help you explore Laravel packages today?