List Classes In Directory Laravel Package

Product Decisions This Supports

• Feature feasibility for auto-discovery: This package answers a recurring product question — "can we let customers/drop in a class and have the app find it?" It's the primitive behind Laravel-style auto-registration of console commands, event subscribers, policies, custom validation rules, or module service providers. If discovery is on your roadmap (plugin system, modular monolith, white-label extension points), this is a ~1-day spike.
• Build vs. buy: The capability is genuinely small (scan a directory, return FQCNs), so the honest default is build. This package only wins as a buy when you don't want to own tokenizer/PSR-4 edge cases — a few hours of engineering vs. a few hours of dependency review. Treat it as a time-boxed accelerator, not architecture.
• Architecture decision — modular monolith vs. explicit registration: Auto-discovery lets you ship a "drop a folder in app/Modules and it works" developer experience. That's a DX/marketing feature for platform or SDK teams, and it materially affects onboarding time for internal or third-party integrators.
• Tooling and codegen roadmap: Enables make: style generators, scaffolding wizards, documentation/schema generation, and CI guardrails ("every class implementing PaymentGateway must be registered") — all things that reduce support burden rather than ship user-facing value.
• Deprioritization signal: 24 stars, 0 dependents, and an opportunity score of ~44 says the market has already decided this is a commodity. Do not build a roadmap theme around it; scope it as an internal utility with an exit ramp.
• Explicit non-goal: Discovery is not a substitute for a DI container or Laravel's package discovery. If a feature requires runtime discovery of configurable behaviour, prefer Laravel's discover conventions or explicit config, and use this only for dev-time/tooling paths.

When to Consider This Package

Consider it when:

• The consumer is a dev-time or boot-time tool — generators, linters, static checks, docs, CI assertions — where a filesystem scan is acceptable.
• You need FQCNs from arbitrary directories or single files, including non-PSR-4 layouts, and you'd otherwise hand-roll RecursiveDirectoryIterator + token parsing.
• You're prototyping a plugin/module discovery feature and want to validate the UX before investing in a cached, production-grade implementation.
• The team is small and the cost of owning a tokenizer-based scanner outweighs the cost of vetting a dependency.

Look elsewhere or build in-house when:

• The path is request-hot. Directory scanning on every request is a performance anti-pattern; you need a build-time classmap, cached manifest, or Laravel's config/package discovery instead.
• You need attribute/annotation-based collection — olvlvl/composer-attribute-collector targets that problem directly.
• You need the most robust, battle-tested scanner — composer/class-map-generator (the PHPStan/Composer workhorse) has far more usage and handles PSR-4/classmap/exclusion edge cases better; symfony/finder plus a tokenizer is the DIY path.
• You require vendor SLA, security review depth, or long-term support — single-maintainer package with one recent release and zero dependents means bus-factor and abandonment risk sit with you.
• Discovery semantics must be deterministic and auditable (e.g., regulated environments, allowlists) — explicit registration is safer and easier to reason about than implicit scanning.

Adoption checklist: pin the version, wrap it behind your own ClassDiscovery interface so swapping to composer/class-map-generator is a one-file change, benchmark scan time against your largest module directory, and add a test that fails if discovery silently returns zero classes.

How to Pitch It (Stakeholders)

To executives (one paragraph): We're evaluating a small, MIT-licensed PHP utility that lets the application find classes in a directory automatically. It's the enabler for two things teams keep asking for: a plugin/module system where new functionality is added by dropping in code rather than editing a central registry, and developer tooling that cuts boilerplate for scaffolding and CI checks. Cost is effectively zero — no infrastructure, no licensing, roughly a day of integration — and the risk is contained because we'll wrap it behind our own interface so it can be replaced in an hour. It is not a strategic bet; it's a cheap unblocker for DX and platform extensibility work, and I'd recommend a time-boxed spike rather than a roadmap commitment.

To engineering (summary): wyrihaximus/list-classes-in-directory returns fully qualified class names from directories and files, which is the piece we'd otherwise write ourselves for command/subscriber auto-registration and for codegen tooling. It's actively-ish maintained (release mid-2024) but small: ~24 stars, no dependents, single maintainer — so treat it as a convenience, not a foundation. Requirements before merge: (1) consume it only at boot or in CLI/CI contexts, never in the request path; (2) cache or manifest the results where scans would repeat; (3) put it behind an internal ClassDiscovery contract so we can move to composer/class-map-generator if edge cases bite; (4) add a test asserting non-empty discovery so a silent autoload/PSR-4 regression fails loudly. If the spike shows we need attribute collection or configurable runtime discovery, we escalate to a proper design rather than extending this dependency.