Code Unit Reverse Lookup Laravel Package

Product Decisions This Supports

• Build vs. buy (buy, and mostly "don't even think about it"): This is a single-purpose utility that answers one question — "which function or method does File.php:412 belong to?" Writing and maintaining that logic in-house is pure cost with no differentiation. Adopt it or inherit it transitively; don't staff it.
• Developer-experience roadmap: It's the plumbing behind human-readable coverage/report output. If a roadmap item is "make CI failures and coverage reports actionable," packages like this are how you get OrderService::calculateTotal() instead of src/OrderService.php:412 in PR annotations and dashboards.
• Feature enablement for internal tooling: PR diff annotations, test-to-code mapping (test impact analysis / "which tests cover this method"), mutation-testing reports, profiler and error-tracker enrichment, code-review bots. Each is a small feature that becomes trivial once line→callable resolution exists.
• Dependency posture decision: It ships transitively via PHPUnit / php-code-coverage, so it's already in your lockfile. The PM decision is whether to take a direct dependency (only if you call the Wizard API yourself) or treat it as invisible infrastructure (default).
• Risk acceptance: Marked "No Maintenance Intended" / low-maintenance. That's acceptable for a tiny, stable, BSD-3 leaf library — but it is an explicit decision to accept "as-is" support, and it should be recorded as such rather than discovered in an audit.
• Prioritization: Effort is hours, not sprints. It should never win a planning argument; it should just be a line item in a dev-tooling ticket.

When to Consider This Package

Adopt (or accept transitively) when:

• You're building PHP developer tooling that ingests line-level data — coverage reports, profiler output, stack traces, linter output — and needs to label those lines with their enclosing callable.
• It's needed only at development / CI time — install with --dev.
• You're already in the PHPUnit ecosystem, where it arrives for free and the integration is already proven.
• You need a small, stable, permissively licensed (BSD-3) dependency and can live without a vendor relationship.
• Your accuracy needs are coarse — "roughly which unit owns this line" is sufficient.

Look elsewhere when:

• You need real static analysis: precise handling of closures, arrow functions, anonymous classes, traits, attributes, multi-line signatures, or cross-file resolution — use nikic/php-parser, roave/better-reflection, or phpDocumentor instead. This package scans source lines; it is not an AST.
• You need guaranteed maintenance, security patching, or an SLA. The "No Maintenance Intended" badge is explicit; if your organization's policy forbids unmaintained dependencies, this fails that gate regardless of how harmless it is.
• You need it in a production request path — it re-reads source files from disk, which is fine for CI and wrong for hot runtime code.
• You're not on PHP, or you'd be wrapping it in a service boundary — that's a smell, not an integration.
• The Dependents: 0 figure in metadata is misleading (real usage is via php-code-coverage); don't use it as a signal either way, but do verify your own lockfile rather than trusting registry stats.

How to Pitch It (Stakeholders)

To executives: This is a zero-cost, BSD-licensed utility that's already sitting in our dependency tree via PHPUnit. Its only job is turning a raw file-and-line reference into a named function or method, which makes our CI output and coverage reports readable and triage-able. No procurement, no license fees, no vendor relationship, no product differentiator — it's infrastructure, and it's already paid for. The one governance note: the maintainer has marked it low-maintenance, so we pin the version and keep it isolated behind a thin wrapper so it's replaceable in an afternoon.

To engineering: One class, one method: give it a file and a line, get back the enclosing callable. It's a transitive dependency of php-code-coverage, so don't add it to composer.json unless you're calling it directly — and if you are, add it as --dev. Don't fork it, don't vendor it, don't build a service around it. Do put a tiny adapter in front of it if the output ends up in anything user-facing, so that when you eventually need AST-grade precision for closures and anonymous classes we can swap in a PHP-Parser-based implementation without touching call sites. It's line-scanning, not parsing — treat its answers as "good enough for reports," not "correct for refactoring." Cost to wire up: hours.