- How do I install sergix44/container?
- Install it with Composer by running composer require sergix44/container in the root of your project. Composer will pull in the package and its PSR-11 dependency, and the container classes become available through the autoloader. After that you can instantiate the container and start registering your bindings.
- Is sergix44/container PSR-11 compliant?
- Yes. The package implements the PSR-11 container standard, which means you interact with it through the Psr\Container\ContainerInterface contract. Services are fetched with get() and existence is checked with has(), and a missing entry throws a Psr\Container\NotFoundExceptionInterface. This compliance lets you type-hint the PSR-11 interface in your own code and swap in another container implementation later.
- How is sergix44/container different from Laravel's built-in service container?
- Laravel already ships a full-featured container that is tightly integrated with the framework's service providers, facades and bootstrapping. sergix44/container is a much smaller, standalone container focused on a simple API for binding services, managing singletons and resolving dependencies. It is a good fit when you want minimal configuration and no framework overhead, for example inside a reusable package or a plain PHP script.
- How do I bind a service and resolve it from the container?
- You register a binding on the container, typically as a closure or a class reference, and then resolve it with get() using the binding identifier. A closure binding keeps object construction in your hands, which is useful when a service needs specific constructor arguments. Once resolved, the instance is returned so you can pass it into controllers, commands, or other services.
- How do singletons and shared instances work in this container?
- The container supports managing singletons, meaning a service is constructed once and the same instance is returned on every subsequent resolution. This is the pattern you want for stateful services such as configuration objects, database connections or caches. Non-shared bindings, by contrast, produce a fresh instance each time they are resolved.
- Can I use sergix44/container outside of Laravel in a plain PHP project?
- Yes. Because the package is a standalone PSR-11 container, it works in any PHP application, including CLI tools, queue workers, small frameworks and legacy codebases. You just install it with Composer and wire up your bindings, with no Laravel bootstrap required. That portability is one of the reasons to prefer a PSR-11 implementation over framework-specific containers.
- Which PHP and Laravel versions does sergix44/container support?
- The exact constraints are defined in the package's composer.json, so check that file before adding it to a project on an older runtime. Because it depends on the PSR-11 container interfaces, it follows the PHP versions those interfaces support, which covers modern PHP 7.x and 8.x releases. It does not require a specific Laravel release since it is framework-agnostic.
- How do I test code that depends on this container?
- Type-hint Psr\Container\ContainerInterface or your own interfaces rather than the concrete container class, then substitute real bindings with test doubles in your test setup. In unit tests you can register a mock or fake implementation and resolve the class under test from a fresh container for each test. This keeps tests isolated and avoids booting a full application just to resolve dependencies.
- Is sergix44/container fast enough for production use?
- The container is intentionally lightweight and avoids heavy reflection or configuration parsing, so resolution overhead is minimal. For best results, resolve services once and reuse them through singleton bindings instead of resolving on every request or loop iteration. Combining it with Composer's optimized autoloader keeps startup cost low in production deployments.
- What alternatives should I consider before choosing sergix44/container?
- Common alternatives include Laravel's built-in container for framework projects, PHP-DI for annotation and autowiring-heavy setups, League\Container for a feature-rich PSR-11 implementation, and Symfony DependencyInjection for compiled container configurations. If you only need simple bindings, singletons and PSR-11 interoperability with minimal configuration, sergix44/container is the lighter choice. Compare feature sets against what your application actually uses before switching.