Class Info Laravel Package

Technical Evaluation

A TPM should treat crodas/class-info as a narrow static-analysis utility, not a strategic platform dependency. It answers one question—"what classes/functions are defined in this file?"—which can support Laravel tooling such as module/package discovery, code generation, documentation inventory, migration analysis, and architecture governance. It is not Laravel-aware, does not provide auto-discovery, routing, container integration, or reflection replacement.

• Architecture fit: Best fit is as a dev-time or build-time adapter behind an internal interface, e.g. FileSymbolScanner. Avoid using it in request paths, domain services, or as the sole source of truth for application wiring. Laravel already offers Composer classmaps, Reflection, Symfony Finder, and mature parsers such as nikic/php-parser; this package should be justified by a concrete, narrow scanning need.
• Integration feasibility: Likely feasible via Composer if PHP version constraints and license are acceptable. The API is probably simple, but integration still requires a wrapper to normalize output, handle paths/namespaces, and isolate the app from package abandonment or replacement.
• Technical risk: High relative to value. Five stars and zero dependents imply low adoption, limited production evidence, and probable bus-factor risk. Risks include stale PHP compatibility, parser edge cases, silent false negatives, namespace/conditional-declaration handling, and unclear behavior on modern syntax such as enums, attributes, readonly classes, and anonymous classes. If the package executes or includes files rather than tokenizing them, security risk increases materially.
• Key questions: What license applies? Which PHP versions are supported? Does it use token_get_all or execute files? How does it resolve namespaces, multiple namespaces, traits, interfaces, enums, and conditional declarations? Does it detect anonymous classes, nested functions, or functions inside conditionals? How does it handle parse errors, symlinks, generated files, and duplicate symbols? Are there tests and CI? What are its memory/time characteristics on large repositories? Is it maintained, and what is the fallback?

Integration Approach

Use it only behind an internal abstraction and only where static symbol discovery is genuinely needed. A TPM should sponsor a small spike, not a broad rollout.

• Stack fit: Suitable for an Artisan command, CI job, package/module scanner, code generator, or documentation inventory tool. Register it as a dev dependency where possible and bind it through a Laravel service provider only if runtime tooling needs it. Keep output as DTOs so the rest of the app does not depend on the package's array/object shape.
• Migration path: There is no data migration. If replacing an existing scanner, run the old and new implementations against the same fixture repository and compare class/function inventories before switching. If adopting, isolate it in a branch or internal package, pin the Composer version, and keep a replacement path via nikic/php-parser or a small token_get_all wrapper.
• Compatibility: Validate against the target Laravel and PHP matrix—e.g. Laravel 10/11/12 and PHP 8.1+. Check Composer constraints, autoload behavior, namespace assumptions, and Windows/Linux path handling. Do not assume compatibility from the package description alone.
• Sequencing: 1) Confirm license, security behavior, and PHP support. 2) Run a time-boxed spike against a representative Laravel codebase, including modern syntax and generated files. 3) Build an adapter with fixture-based tests and a fallback implementation. 4) Pilot in a non-critical CI or developer command. 5) Benchmark and add caching by file hash if used repeatedly. 6) Decide to adopt, fork, or replace. 7) Roll out with an owner, pinned version, and documented fallback.

Operational Impact

Operationally, this is a low-cost utility only if constrained and owned. Without ownership, it becomes a silent single point of failure in tooling.

• Maintenance: Expect to own it internally. Upstream activity is likely low, dependents are zero, and security/PHP-version updates may not arrive. Budget for periodic compatibility checks, a pinned version, and a fork-or-replace contingency.
• Support: There is no vendor support model. Provide internal documentation, runbooks, fixture tests, and a clear escalation owner. TPM should not position this as a supported platform capability.
• Scaling: File scanning is CPU- and I/O-bound. Avoid per-request use; run in CI/build jobs, limit scan scope, parallelize where possible, and cache results by file path plus hash. Large monorepos can increase memory and wall-clock time.
• Failure modes: Modern-syntax parse failures, silent false negatives, missed conditional declarations, namespace collisions, symlink/path issues, generated or vendored files, duplicate symbols, timeouts, and memory exhaustion. If the package executes files, add a security review and prohibit it in untrusted paths. Monitor discovered-symbol counts and fail loudly on parse errors rather than accepting incomplete inventories.
• Ramp-up: The basic API is likely easy to learn; edge-case handling requires PHP tokenizer/static-analysis knowledge. Allocate a small owner group, create representative fixtures, and document known limitations before broader developer use.