Reflection File Laravel Package

Product Decisions This Supports

• Build vs. buy for source-code introspection. This package answers a narrow question: do we need to reflect over a file (its namespace, declared classes, use statements, structure) rather than over an already-loaded symbol? If a roadmap item requires scanning source files — dynamic class discovery, attribute/annotation-driven registration, code generation, custom artisan scaffolding, module auto-registration — this is a candidate primitive rather than writing our own tokenizer wrapper.
• Dependency footprint for tooling features. It is a leaf-level utility, not a framework. Adopting it does not shape architecture, so it can be evaluated purely as an implementation detail inside dev-tooling or codegen features, decoupled from customer-facing roadmap commitments.
• Feature scoping for internal developer-experience work. Useful signal when sizing "convention over configuration" features (auto-discovered handlers, event listeners, policy registration). The decision it informs is whether static file scanning is cheap enough to ship now versus deferring to explicit registration.
• Transitive dependency triage. With zero stars, zero dependents, and a 2019 release, the realistic PM decision is not "adopt" but "do we need to vendor, fork, or replace this if it arrives transitively" (e.g., via rikudou/class-finder). That is a maintenance-budget and supply-chain decision, not a product one.
• Make vs. mature-alternative. It sharpens the comparison against nikic/php-parser (AST, heavier, actively maintained), roave/better-reflection (full static reflection, heavier), and PHP 8's native reflection plus attributes. The PM-relevant axis is capability per unit of maintenance burden.

When to Consider This Package

Consider it when:

• The need is genuinely narrow: read a PHP file's namespace/class declarations without a full AST, inside a small internal tool or codegen step.
• The codebase targets PHP 7.x-era idioms and you cannot assume PHP 8 attributes/native reflection for the same job.
• You are already inside the RikudouSage ecosystem (e.g., class-finder) and this is already on the dependency graph — in which case the decision is pinning and auditing, not adopting.
• The team accepts a vendored, effectively unmaintained utility: small surface area, readable source, WTFPL (permissive, no attribution burden — though have legal confirm, since WTFPL is unusual and some corporate policies reject it by name).
• You are willing to fork it internally and own it. Given its size that is plausible; given its age, it must be an explicit choice.

Look elsewhere when:

• You need guaranteed maintenance, security response, or a support contract — there is none. Last release February 2019, no dependents, no community.
• The requirement is real static analysis: use nikic/php-parser or roave/better-reflection. Do not stretch a file-reflection shim into an analysis engine.
• You are on PHP 8.1+ and native reflection/attributes already cover the use case — adding a dormant dependency is pure liability.
• The feature is customer-facing or revenue-critical: no bus factor, no changelog cadence, no test/CI signal to rely on.
• Your dependency policy requires an actively maintained package with a release within N months — this fails on any reasonable threshold.
• Class/file discovery is the actual need: composer/class-map-generator or symfony/finder cover it with real maintenance.

How to Pitch It (Stakeholders)

For executives (one paragraph): This is a tiny, single-purpose PHP utility for reading information out of source files. It is free (WTFPL), has no known dependents, no stars, and has not been updated since early 2019 — meaning we would be adopting code nobody maintains. That is acceptable only as an internal, vendored helper inside developer tooling, where failure is low-impact and we can fix it ourselves. It is not a platform or architecture decision, and it should not enter any customer-facing or revenue-critical path. Recommendation: do not add it as a new dependency; if it appears transitively, pin it, audit the source (it is small), and plan to replace it with PHP 8 native reflection, nikic/php-parser, or an in-house equivalent at the next touch.

For engineering (the practical case): The value proposition is a minimal wrapper that lets you reflect over a file's contents — namespace, declared classes — without pulling in a parser. It is a building block for class discovery and codegen. The costs are equally concrete: unmaintained since 2019, no CI or release cadence to trust, an unconventional license your legal team may flag, and no upstream to escalate bugs to. If we use it, we vendor the source, add it to our owned-code list, and write our own tests around the API surface we actually call. If we need more than trivial file introspection, skip straight to nikic/php-parser or PHP 8 attributes — the extra weight buys maintenance, correctness, and a community we can lean on.