Classname Mapper Laravel Package

Product Decisions This Supports

• Discovery vs. runtime reflection architecture. The package's one capability — given a set of PSR-4 (and legacy PSR-0) namespace prefixes, resolve a fully qualified class name to an absolute file path without autoloading it — is the primitive that makes build-time discovery possible. This is the decision "do we scan and require classes at boot, or do we resolve and compile ahead of time?"
• Build vs. buy for auto-registration in our own packages. It shows the minimum viable API surface for convention-based registration (drivers, macros, policies, event listeners, Livewire-style components). At roughly 11 stars and 0 dependents, the honest read is: the pattern is worth adopting, the dependency is not. Use it to price an in-house implementation (~100–200 lines) rather than to shortlist a vendor.
• Roadmap input for compile-time performance work. If a milestone includes opcache.preload generation, container compilation, or eliminating boot-time scans, this package is prior art for the file-resolution half of that work.
• Legacy modernization. If any part of the estate still runs on the Mouf / thecodingmachine stack, this is a line item in the "plan the exit" backlog, not something to extend.
• Concrete use cases: DI container compile passes; attribute/docblock scanning for auto-registered services; dead-code and orphan-class detection in CI; parity with Laravel's own extra.laravel.providers auto-discovery for internal packages; plugin registries in a multi-tenant product.

When to Consider This Package

Adopt the idea freely; adopt the package only under narrow conditions.

Consider it (or a vendored copy) when:

• You need prefix → path resolution as a standalone primitive, decoupled from Composer's autoloader and without require-ing files.
• You are already inside the Mouf/thecodingmachine ecosystem and the surrounding code expects this exact API.
• You accept the maintenance posture: last release January 2019, 11 stars, 0 dependents. Treat it as unmaintained. Verify PHP 8.x compatibility yourself and expect to vendor or fork.

Look elsewhere when:

Avoid it outright if you require PHP 8.1+ attribute/enum awareness, a security-response process, or a dependency you can put in front of an auditor. The low opportunity signal is not a flaw in the problem — it's a signal that this is a small primitive, not a product. Any competent engineer can reimplement it in a day.

How to Pitch It (Stakeholders)

To executives (one paragraph): This is not a dependency request. It's a design pattern worth roughly half a day of engineering. The capability — mapping a class name to a file without loading it — is what lets us move expensive boot-time class scanning into a build step, cutting per-request work. The package itself is stale (last release 2019, no downstream users), so the recommendation is to lift the approach, not the code. Cost is negligible; the benefit is a measurably faster and more predictable boot path.

To engineering (the actual ask): We need reliable class-to-file resolution for a set of PSR-4 roots so we can compile discovery artifacts (container bindings, registered drivers, preload lists) instead of reflecting at runtime. The candidate package demonstrates the API but is effectively abandoned — no PHP 8.1 assurance, no security process, zero dependents. Two acceptable paths: (1) adopt composer/class-map-generator, which is the maintained equivalent with matching resolution semantics, or (2) write a ~150-line adapter if we need control over caching, error handling, and namespace filtering. Recommend a one-day spike against path (1) with path (2) as fallback. Do not add mouf/classname-mapper to composer.json.