- How do I install and configure laravel-auto-binder?
- Install it with composer require michael-rubel/laravel-auto-binder, then publish the config file if the package ships one so you can declare which project folders should be scanned. You point the package at your contract and implementation directories, and it derives the interface-to-concrete pairs from matching namespaces and class names. After that, constructor injection of those interfaces resolves without any manual $this->app->bind() calls in your service providers. Always re-read the config schema for the major version you install, since 6.0.0 is a major bump.
- Which Laravel and PHP versions does laravel-auto-binder support?
- Release 6.0.0 added Laravel 11 support, and earlier 5.x releases target older Illuminate versions. Because Laravel 11 support arrived in a major version, you should assume the illuminate/* constraint range and possibly the PHP floor changed, and confirm both against your own stack before upgrading. There is no published Laravel 12 support as of this release, so treat Laravel 12 and PHP 8.4 as an open question and check the repository's composer.json and open issues. Read the actual constraint block rather than inferring from the release title.
- What happens when multiple implementations match one interface?
- Convention-based scanning cannot know which of two similar implementations you meant, so ambiguity is a real risk with this pattern. Depending on the package version the outcome may be an exception, first-match-wins, or a silent override, and there is no compile-time signal either way. The safest approach is to keep exactly one implementation per interface inside the scanned folders and bind genuinely variable cases explicitly in a service provider. Verify the behaviour in your installed version before relying on it in production.
- Does laravel-auto-binder support contextual bindings or tagged bindings?
- No. The package replaces straightforward interface-to-implementation bindings only, so when()->needs()->give() contextual bindings, tagged bindings, and runtime selection among several implementations still have to be written by hand. That is by design: it is a container-wiring convenience layer, not an extension of the container itself. Keep a normal service provider for the advanced cases alongside the scanned conventions.
- Is there a performance cost from scanning folders on every boot?
- The package resolves its interface map by scanning your configured directories, so the key question is whether that scan happens once and is cached or is re-derived on each boot. Confirm the map is built at boot and reused, and check that nothing breaks under config:cache or in long-running workers like Octane and queue consumers. If the scan runs per request in your setup, cache the resulting bindings in your own provider instead. Measure with a warmed container before assuming it is free.
- Is laravel-auto-binder still maintained?
- It is a single-maintainer package with a small user base, and 6.0.0 shows a merged Laravel 11 support PR, a reverted internal refactor, and Dependabot activity, which indicates a maintainer still responding. However, you should verify the repository's archive status and the commit date of the 6.0.0 tag yourself, because release notes alone do not prove the project is active today. There is no vendor SLA or support channel, so plan for the possibility of forking the package if it stalls.
- What are the alternatives to laravel-auto-binder?
- The most direct alternative is simply writing $this->app->bind() lines in a service provider, which stays explicit and greppable but grows with the number of interfaces. Laravel 11 also ships native container attributes like #[Bind] and #[Singleton] on interfaces, which give you convention-like wiring without a third-party dependency. If you need contextual or tagged bindings, those must be configured explicitly regardless of which approach you choose. Compare on debuggability: implicit scanning makes bindings invisible in your providers, so container dumps become your audit path.
- How do I test that the interface bindings actually resolve?
- Write a test that resolves each interface from the container with $this->app->make(YourInterface::class) and asserts the returned class, so convention mismatches fail in CI rather than in production traffic. Because the bindings are invisible in AppServiceProvider, container dumps and targeted resolution assertions are your main audit path. Also add a test that boots the app with config cached, since that is where scanning problems usually surface. A small data-provider driven test over your contracts folder catches ambiguous matches early.
- What happens if an implementation is missing or the convention does not match?
- If the scanner cannot find a matching implementation, the failure typically surfaces later as a BindingResolutionException when the interface is first resolved, unless the package fails fast at boot. That distinction matters in production, because a late failure means a container error on real traffic rather than a startup crash. Test the missing-implementation case deliberately and decide whether you want a boot-time check in your own test suite. Keeping interfaces and implementations in the exact expected namespaces avoids most of these surprises.
- Is upgrading from 5.x to 6.0.0 safe for my application?
- 6.0.0 is a major release, so treat it as breaking: the Illuminate constraint range changed to include Laravel 11, and there may be a PHP floor change or config and namespace adjustments. The release notes do not enumerate the breaking changes, so diff the source and read composer.json rather than assuming a drop-in upgrade. Also check whether singleton, scoped, or transient lifetimes changed, and whether the scanned-folder configuration key names are the same. A short spike against your current and next-target Laravel versions is the cheapest way to find out.