Laminas File Laravel Package

Product Decisions This Supports

• Dependency triage and risk accounting. This is not a package you choose; it is one you inherit. It is archived upstream with 13 stars, meaning zero maintainer capacity, no security response, and no roadmap. The PM decision it informs is whether an existing Laminas/Zend-derived dependency chain is acceptable to carry, or whether it triggers a modernization workstream.
• Build vs. buy vs. delete. The capability — "given a class name, find the file that defines it" — is now one line of PHP in the platform: (new ReflectionClass($class))->getFileName() or Composer\Autoload\ClassLoader::findFile($class). The only durable differentiator left in this package is tokenizer-based scanning of .phar archives and files that Composer does not autoload. That is a narrow enough gap that "write 30 lines in-house" beats "adopt an archived vendor library" for any greenfield work.
• Feature scoping for reflection-driven tooling. Where it is legitimately in play: DI container configuration parsing, annotation/attribute discovery, proxy and code generation pipelines (it is a historical dependency of laminas-di and laminas-code), and plugin/module discovery by class name. If your roadmap contains any of these, this package is a supporting detail of an existing framework choice, not a feature decision in its own right.
• Modernization sequencing. The archived flag converts a passive dependency into a dated item on the tech-debt roadmap. The relevant planning question is not "should we adopt it" but "which of our Laminas-family upgrades is the natural point to shed it," since the exit cost is low (BSD-3-Clause, tiny surface, trivially replaceable).
• Licensing and compliance sign-off. BSD-3-Clause is permissive and unproblematic; this will clear legal review without negotiation, which removes the usual blocker for keeping it in the tree short-term.

When to Consider This Package

Reasonable to keep (not adopt):

• It already arrives transitively via laminas-di, laminas-code, or a legacy Zend Framework 2 stack. Rip-out cost exceeds the risk in the near term — pin the version, add it to a dependency watchlist, and move on.
• You genuinely need class-to-file resolution across .phar archives or code that is not registered with Composer's autoloader. This is the one scenario where reimplementation is non-trivial.
• You are mid-migration off a Zend/Laminas codebase and need behavior parity while you port.

Look elsewhere:

• Anything greenfield. Use ReflectionClass::getFileName() or Composer's ClassLoader::findFile(). Standard library, no dependency, no archival risk.
• Static analysis or large-scale code intelligence. Reach for nikic/php-parser or roave/better-reflection, which are actively maintained and do far more than path lookup.
• Any requirement for upstream support, CVE response, or an SLA. The archive status is disqualifying; there is no one to file an issue with. If a security review gate asks "who maintains this," the honest answer is "nobody," and that answer should fail the gate for a customer-facing or regulated surface.
• PHP-version forward-compatibility guarantees. The last tag is 2024-12-05 and the repo is frozen; treat any claim of future PHP support as unverified. Validate against your target runtime before relying on it.
• Anywhere a failure in class resolution is user-visible or revenue-affecting. Archived code in a hot path is an unowned single point of failure.

Adoption verdict: Do not add this as a direct dependency. Accept it only as an inherited transitive one, with the explicit expectation that it will be removed at the next major framework upgrade.

How to Pitch It (Stakeholders)

For executives (one paragraph): We have identified a small, permissively licensed PHP utility in our dependency tree that locates the source file for a given class. It is functionally replaceable by built-in PHP and Composer features, it is no longer maintained by its authors, and its community footprint is negligible. There is no feature value in it and no license or cost exposure. The recommendation is to leave it in place where it already exists, pin the version, and schedule removal alongside our next framework upgrade — a low-effort cleanup, not a project. The risk is not technical failure today; it is carrying unowned code past the point where it matters.

For engineering (framing): Treat laminas/laminas-file as frozen infrastructure, not a library. Do not build new code against its API; if you need class-to-file resolution, use ReflectionClass::getFileName() or the Composer ClassLoader. The only retained capability worth preserving is tokenizer-based scanning of .phar archives, and if we depend on that, we should own a small internal implementation rather than an archived one. Pin the current version, add it to the dependency-review list, and flag it in any upgrade ticket that touches laminas-di or laminas-code, since that is our natural window to remove it.