Classname Mapper Laravel Package

Technical Evaluation

Architecture fit. mouf/classname-mapper is a narrow utility: it resolves which PHP file(s) a class will be loaded from, based on autoload metadata. In a Laravel/PHP context this capability already exists inside Composer's ClassLoader (findFile(), getClassMap(), getPrefixesPsr4()), which Laravel relies on for package discovery, container resolution, and optimized autoloading. The package therefore fits only in adjacent tooling: static analysis, module/plugin enumeration, upgrade audits, class-to-file reporting, or custom scanners that must inspect mappings without instantiating classes. It is not a fit for the request lifecycle, servicecontainer, or any hot path. Score (0.345) and adoption signals (11 stars, 0 dependents) are consistent with a niche, low-leverage library.

Integration feasibility. Installable via Composer as a plain library; no Laravel service provider or framework coupling expected. Feasibility hinges on PHP constraint compatibility: the last release is January 2019, predating PHP 8, so a compatibility spike against PHP 8.1–8.3 is mandatory before any commitment. Integration itself is small (a wrapper plus parity tests), likely 1–3 days for a spike and 3–5 days to harden.

Technical risk. High relative to delivered value. The package is effectively unmaintained, has no dependent ecosystem, and will not receive PHP 8/Composer 2 fixes upstream. Behavioral risk is more significant than security risk: it may diverge from Composer's real resolution semantics for authoritative classmaps, exclude-from-classmap, PSR-4 prefix collisions, case sensitivity, and multiple autoloaders. Supply-chain surface is tiny, but governance burden (review, fork ownership, CI) is not zero.

Key questions.

• Does it support Composer 2 metadata, optimized dumps, and --classmap-authoritative?
• Does it handle exclude-from-classmap, PSR-0/PSR-4/classmap/files autoload rules, and vendor-vs-app paths correctly?
• Is it PHP 8.1+ clean (types, deprecations), and what is the license?
• Can the same outcome be achieved with Composer\Autoload\ClassLoader and Composer\Autoload\ClassMapGenerator (likely yes)?
• Is the use case dev/CLI-only, or is someone proposing runtime use? If runtime, why?
• If adopted, who owns the fork and the PHP-upgrade maintenance?

Integration Approach

Stack fit. PHP/Laravel only. Position it as a require-dev dependency or internal tool consumed by an Artisan command, static analyzer, or migration script. If a runtime need is proven, isolate it behind an interface, generate results at build time, and cache them — never call it per request.

Migration path. Greenfield adoption; there is no existing integration to migrate. Run a spike branch that compares the package's output against Composer's ClassLoader::findFile() across the application's full class set. If parity is high, wrap it; if gaps appear in edge cases, do not adopt and use Composer's APIs directly. For teams replacing a bespoke class scanner, put the new resolver behind a facade with the old implementation as fallback, then retire it after parity is demonstrated.

Compatibility. Pin the version and test across the supported PHP matrix (e.g., 8.1–8.3) and both normal and optimized Composer dumps. Cover PSR-4, PSR-0, classmap, files autoload, vendor packages, and Windows/CI path handling. Octane/Swoole is irrelevant if the dependency stays in dev/CLI tooling. Verify license compatibility before vendoring.

Sequencing.

1. Confirm the use case is enumeration/resolution for tooling, not runtime class loading.
2. Run a compatibility spike on PHP 8.x with Composer 2, including authoritative classmaps.
3. Build a thin adapter and a parity test suite against Composer's autoloader.
4. Benchmark on the largest target codebase; decide build-vs-buy.
5. If adopted, vendor or fork with named ownership, pinned Composer version in CI, and upgrade tests.
6. Document it as an internal utility with a clear "do not use at runtime" note.

Operational Impact

Maintenance. Treat as unmaintained since 2019. The code surface is small, which limits effort, but all PHP-upgrade and Composer-evolution work is yours. Budget explicit ownership for annual PHP upgrades and any Composer autoload changes.

Support. No vendor support and effectively no community (11 stars, 0 dependents). Internal documentation, tests, and an escalation path ("we own the fork") are required before production-adjacent use.

Scaling. Resolution is in-memory metadata lookup and cheap per call, but repeated scans over large codebases add up. Generate and cache maps at build time; keep the library out of request paths. Throughput is a non-issue for dev/CLI usage.

Failure modes.

• Silent divergence from Composer's actual resolution (wrong file, missed class, case-sensitivity mismatch).
• Breakage under Composer 2.6+/authoritative classmaps or after composer dump-autoload changes.
• PHP 8 deprecations or fatals in unreleased code paths.
• Stale metadata if maps are cached without invalidation.
• Path assumptions that fail on Windows or in containerized CI.
• Autoload side effects if resolution accidentally loads classes.

Mitigations: fail-loud adapter, parity tests in CI, pinned Composer version, map invalidation tied to the autoload dump, and a documented fallback to Composer's native APIs.

Ramp-up. Low for a PHP developer to use; moderate to trust. Roughly one day to spike and a few days to harden and test. The real cost is validation, not learning the API. The TPM recommendation is to treat this as a build-vs-buy decision where Composer's own APIs likely suffice, making adoption optional and probably unnecessary unless a specific enumeration gap justifies it.