- What is michael-rubel/laravel-enhanced-container used for?
- It is a lightweight DX extension for Laravel's service container that adds convenient helpers for binding, resolving, and managing dependencies. Its headline feature is attribute-driven registration: #[Bind], #[Singleton], #[Scoped], and #[Tag] let you declare a class's lifecycle next to the class instead of inside a service provider. It fits best in large, modular, or DDD-leaning codebases where providers have become a registration dumping ground. For a typical CRUD app the value is marginal, since bind, singleton, scoped, and when() already cover most needs.
- How do I install laravel-enhanced-container?
- Installation is a standard Composer require of michael-rubel/laravel-enhanced-container; the package is MIT licensed and has no infrastructure or external service dependencies. The non-trivial part is adoption: because the package extends the container itself, you must swap in the enhanced container during application bootstrap. That is a single-line but globally scoped change, so validate it against your full test suite, a shadow environment, and third-party packages before rolling it out.
- Which Laravel and PHP versions does laravel-enhanced-container support?
- Attribute-based registration requires PHP 8.0 or newer, and the package is typically used on Laravel 10, 11, or 12 with PHP 8.1+. Confirm the exact floor and ceiling in the package's composer.json and README before adopting, because the package tracks Laravel container internals that are not covered by Laravel's backward-compatibility promise. The supported Laravel window is a hard constraint, not a soft one, so check the maintainer's stated policy for new Laravel majors.
- Does laravel-enhanced-container require replacing Laravel's default container?
- Yes. The package augments Illuminate\Container\Container rather than replacing Laravel's binding model, so the application must swap in the enhanced container during bootstrap. This is additive at the API level but cross-cutting at runtime, since every resolution in the app flows through the container. Attribute adoption, by contrast, is per-class and fully opt-in, which allows a genuine incremental rollout after the swap is validated.
- How do #[Bind], #[Singleton], #[Scoped], and #[Tag] attributes work?
- They colocate a class's container lifecycle with the class itself, so an interface-to-implementation map or a singleton declaration lives on the implementation instead of in a service provider. The package also exposes registration and resolution hooks for finer control. Resolution is reflection-based, which puts introspection cost on the hot path and can cause friction with IDE and static-analysis tooling that does not understand attribute-declared bindings.
- Are attribute bindings compatible with php artisan optimize and config caching?
- This is one of the areas you must verify rather than assume. Attribute bindings are reflection-driven at resolution time, and whether they are cached or pre-resolvable under php artisan optimize, config:cache, and route:cache depends on the package's internals. Run your test suite in a fully cached configuration before deploying to production.
- Does laravel-enhanced-container work with Laravel Octane and queue workers?
- It is compatible in principle with Octane and RoadRunner, but scoped-binding and cached-instance correctness under long-running workers is the one area that needs explicit verification. You must prove, not assume, that reset and flush behave correctly across requests, jobs, and worker boundaries. Test scoped and singleton semantics under a real Octane worker before production use.
- How do I test classes that rely on attribute-based bindings?
- Because the package sits on the container, test isolation depends on reset and flush semantics behaving correctly between tests, which should be proven explicitly in your suite. A sound rollout starts with a container swap only, changing no bindings, and treating zero behavioral delta in the full test suite plus a shadow environment as the success criterion. Only then convert a single bounded context's provider to attribute-based registration.
- Do attribute bindings conflict with existing when() contextual bindings or third-party attributes?
- They can. Existing when() contextual bindings and third-party #[Inject]-style attributes may conflict or take precedence in ways that are not obvious, so piloting one bounded context at a time is the safest approach. This surfaces conflicts with third-party packages and existing contextual bindings while every other provider stays untouched. Each phase should be independently revertible.
- Is laravel-enhanced-container production ready, and what are the alternatives?
- Weigh the adoption signals carefully: roughly 88 GitHub stars, zero Packagist dependents, a single maintainer, and one release in the trailing year means there is effectively no production reference base, so any incident you hit is likely the first one. The blast radius is application-wide because every resolution flows through the container. Native bind, singleton, scoped, and when() remain the safe alternative for most projects, with this package being an ergonomic convention layer for large codebases that can accept the maintenance risk.