Finder Facade Laravel Package

Product Decisions This Supports

• Dependency consolidation. This package is a thin static facade over symfony/finder whose only real purpose is one-line file discovery in Sebastian Bergmann's own tooling (PHPUnit, coverage tooling, etc.). Finding it in a dependency tree is a signal of incidental inheritance, not deliberate adoption — it supports a "prune it" decision on the next dependency audit.
• Build vs. buy vs. don't bother. Any build/buy discussion resolves immediately: the capability is one method call over an actively maintained upstream. There is nothing to build and nothing worth buying.
• Internal developer tooling roadmap. If we ship CLI, linting, or test-runner tooling, this is a usable design precedent (static convenience API over a configurable service) and a cautionary tale about wrappers that outlive their usefulness. Adopt the pattern, not the package.
• Modernization and upgrade planning. Archived + unmaintained is a forcing function. In any PHP major-version upgrade, this becomes a listed blocker to remove rather than an item to patch.
• Supply-chain / SBOM hygiene. An archived dependency with an uncleared license flag is a line item to eliminate, not to risk-accept.

When to Consider This Package

Consider it (weakly, narrow cases):

• A legacy codebase already depends on it and removal cost currently exceeds the risk — pin, isolate behind our own interface, and schedule the exit.
• Throwaway scripts or one-off internal utilities where a single static call beats constructing a Finder instance.
• Reproducing an older Sebastian Bergmann toolchain that expects it to be present.

Look elsewhere — use symfony/finder directly — when:

• You need active maintenance, security patching, or supported PHP version guarantees. This package has none; the upstream does.
• The code is production or has a long-term support obligation.
• Testability matters. A static facade is an anti-pattern for application code; Finder's object API composes, mocks, and injects cleanly.
• License clarity matters — the scanner reports NOASSERTION, so legal review is required before adoption regardless of anything else.
• You need anything beyond path + filename pattern matching (depth, size, date, content filters) — you'd end up in the underlying Finder anyway.

How to Pitch It (Stakeholders)

Executive summary. sebastian/finder-facade is a small, archived convenience wrapper around Symfony's Finder component — a static shortcut for locating files by name. It carries no strategic value: 243 stars, zero recorded downstream dependents, no maintenance, and an uncleared license flag. We should not adopt it for new work.

The actual recommendation is dependency hygiene, not a feature decision. We keep using symfony/finder directly. Same capability, actively maintained, one line of code longer. If this package already appears in our tree, it is a cleanup ticket on the next audit — not a project.

For engineering. The package adds ergonomics only, in the context of a larger tool suite; it adds no capability. Any proposal to introduce it should be redirected to a direct Finder call. Removal cost from an existing codebase is typically trivial — path and pattern in, an iterable of SplFileInfo out, usually at a handful of call sites.

For product. No roadmap impact, no user-facing impact, no metrics moved. The decision it informs is a one-line policy statement — "use Symfony Finder, not the facade" — which is worth writing down once so it stops coming up.

Risk framing if pushed. Adopting an archived dependency means we own it the moment we take it, with no upstream fixes and a license our tooling cannot classify. That is a poor trade for saving a constructor call.