- How do I install lorisleiva/lody in a Laravel application and is any configuration required?
- Install it with composer require lorisleiva/lody. No configuration is required because Lody reads your existing Composer PSR-4 mappings automatically. Optional behaviour, such as custom path and classname resolution, can be configured from one of your service providers. The package targets Laravel 11 through 13 on PHP 8.1 and above.
- What is the difference between Lody::files and Lody::classes?
- Lody::files returns a LazyCollection of SplFileInfo objects for every file found under the given path or array of paths. Lody::classes returns fully qualified classnames instead, resolved through PSR-4 conventions and filtered so only existing classes are yielded. Both variants support the same chainable filters, so you can pick files when you need to inspect contents and classes when your goal is registration.
- How does Lody convert file paths into fully qualified class names?
- Lody maps filenames to classnames by following the PSR-4 mappings defined in vendor/composer/autoload_psr4.php. For example, app/Models/User.php becomes App\Models\User when the App namespace points at the app directory. If your project uses a non-standard autoloader, you can override the logic with Lody::resolveClassnameUsing and supply your own resolver.
- Which Laravel and PHP versions does lorisleiva/lody support?
- Lody supports Laravel 11 through 13 and requires PHP 8.1 or newer. Laravel 10 users are limited to v0.4.0, which is no longer supported. The v0.7.1 release is a patch with no API removals or signature changes, so upgrading from v0.7.0 is just a composer update with no code changes.
- How can I filter classes by interface, trait, or abstract status in Lody?
- Lody's custom LazyCollection ships with chainable filters such as isNotAbstract(), isInstanceOf(), hasTrait() and hasMethod(). That lets you declaratively discover, for example, every non-abstract Node implementation or every command using the QueuedCommand trait. Because evaluation is lazy, reflection is only performed on classes that survive earlier filters.
- What happens when I pass a path that does not exist to Lody?
- As of v0.7.1, a missing path returns an empty LazyCollection instead of raising an error. This keeps every step of the fluent chain returning a collection, which is consistent with the rest of the API. The trade-off is that path validation becomes the caller's responsibility, so treat discovery-driven registration as potentially empty by design rather than guaranteed non-empty.
- Is Lody fast enough for large Laravel codebases with thousands of classes?
- Yes. Lazy evaluation keeps memory usage roughly constant even when scanning 10,000 or more classes, and benchmarks show filtered results around 50% faster than eagerly calling get_declared_classes(). Keep in mind that hasMethod() and hasTrait() rely on ReflectionClass, so cache results if you scan the same directories repeatedly, for example during deployments.
- How do I customise the path resolution logic in Lody?
- Call Lody::resolvePathUsing() from a service provider with a closure that receives the path you passed in. The default behaviour appends relative paths to base_path() and leaves absolute paths, which start with a slash, untouched. Return a normalised path from the closure, and consider replacing backslashes with forward slashes as a safeguard on Windows.
- Can I use Lody outside of Laravel in a plain PHP project?
- Lody exposes a setBasePath() method for standalone use, but you lose Laravel helpers such as app()->getNamespace(). For non-Laravel projects, combining Symfony Finder with ReflectionClass is usually simpler and has fewer moving parts. Lody is designed and tested as a Laravel-first package, so standalone mode is a convenience rather than a supported target.
- What are common use cases for Lody in Laravel and how does it compare to manual registration?
- Typical uses include auto-registering event listeners, policies, validation rules or Artisan commands from a directory, and discovering test helpers exposing generateTestData(). It replaces long manual register() lists in service providers with a single declarative chain. Compared with manual registration it is more flexible, but it shifts responsibility for path validity and security onto the caller, so restrict scans to trusted directories such as app/.