Type Parser Laravel Package

Product Decisions This Supports

• Build vs. buy for type introspection. This package answers a narrow but recurring question in PHP tooling: "what type is this property, according to its @var annotation?" That makes it a candidate for the buy/borrow side of build-vs-buy analysis whenever a roadmap item depends on reading PHPDoc types — DTO hydration, serializer/denormalizer layers, admin-panel form generation, API schema/documentation generators, or static-analysis-style linting rules.
• Feature scoping for data-mapping and admin tooling. If the roadmap includes auto-generating forms, filters, or validation rules from model/DTO properties, property-type parsing is a hidden dependency. This package lets you prototype that capability without committing an engineer to writing a parser.
• Roadmap sequencing for developer-experience work. Type introspection is an enabler, not a user-facing feature. It supports decisions like "ship generic collection support in our serializer next quarter" or "defer richer type inference until we have a shared type model." It helps answer whether a capability is a two-week enabler or a multi-month subsystem.
• Technical-debt and consolidation decisions. If multiple teams already regex-scrape @var comments (common in Laravel codebases handling Collection<int, Model> style annotations), this is a reference point for consolidating that logic behind one internal abstraction instead of maintaining several fragile parsers.
• Dependency policy decisions. With 7 stars, 0 dependents, and a low opportunity score, this is a case study for your "acceptable dependency risk" policy: MIT-licensed, small, forkable — usable as a vendored utility, not as a strategic platform bet.
• Migration and legacy-code assessment. Useful when evaluating tooling to scan older Laravel apps whose type information lives in docblocks rather than native property types, informing decisions about upgrade effort and static-analysis adoption.

When to Consider This Package

Consider it when all of the following hold:

• Your use case is genuinely narrow: you need property-level @var PHPDoc types parsed into a usable representation, and Laravel/PHP native reflection does not cover your needs (generics like array<int, Foo>, class-string unions, array shapes).
• You are prototyping or building an internal tool where a small, MIT-licensed parser is cheaper than writing one — and where you can wrap it behind your own interface so it is replaceable.
• You accept the maintenance reality: you are prepared to vendor or fork it, pin it, and own tests around the behavior you depend on.
• You want zero framework coupling — it is a plain library, usable outside Laravel, which is useful if the same capability must serve CLI tooling, queue workers, or a standalone package.
• Your team already tolerates docblock-driven type information as a source of truth (i.e., you are not betting on native types alone).

Look elsewhere when:

• Adoption signal matters. 7 stars and 0 dependents means effectively no community validation, no ecosystem pressure to keep it correct, and no crowd-sourced edge-case coverage. For anything on a critical path, that is disqualifying.
• You need maintained, battle-tested parsing. Mature alternatives cover overlapping ground — phpstan/phpdoc-parser for rigor, phpdocumentor/reflection-docblock, or symfony/property-info for framework-agnostic type extraction. Prefer those unless this package's specific output shape saves you real work.
• Security, LTS, or compliance review is required. A single-maintainer package with no dependents will not survive a vendor-risk review; do not put it in a position where a CVE or abandonment blocks a release.
• The need is incidental. If docblock parsing is a small part of a larger feature, the integration and abstraction overhead may exceed the value; a few lines of regex plus tests may be the honest answer.
• You expect the surface area to grow. If you will soon need generics resolution, inheritance, promotion, or template types, start with a parser designed for that scope rather than growing this one.

How to Pitch It (Stakeholders)

For executives (one paragraph): We evaluated a small open-source PHP library for reading type information from code comments. It solves a real but narrow engineering problem that several internal tooling ideas depend on — generating forms, API docs, and data-mapping code automatically. The cost is near zero and the license is permissive, but the project has minimal adoption (7 stars, no known dependents), so we should treat it as a component we own rather than a vendor we rely on. Recommendation: use it as a time-saver inside a prototype, behind our own interface, with no public commitment — not as a platform dependency.

For engineering (the substance): It parses property types declared in @var PHPDoc annotations. That is useful precisely where native reflection falls short — generic collections, class-string types, and array shapes — and it is framework-agnostic, so it works in Laravel packages, CLI tools, and queue contexts alike. The tradeoff is maturity: single-maintainer, negligible ecosystem usage, no evidence of edge-case hardening. The mitigation is architectural, not contractual: wrap it in an internal TypeResolver interface, pin the version, and write characterization tests around the annotations we actually support. If it is abandoned or proves wrong on our inputs, we swap the implementation — or vendor the MIT source — without touching call sites.

Recommendation: Approve as an internal, low-blast-radius utility for prototyping, with a one-sprint timebox and an explicit exit criterion. Do not adopt it for customer-facing or release-blocking paths until it has survived a real workload and we have decided whether to fork it. Reassess against phpstan/phpdoc-parser and symfony/property-info before writing any long-lived code on top of it.