- Does sanmai/di-container work in a Laravel application?
- It runs on any PHP project, but it is not a Laravel package: there is no service provider, facade, config file, publishable assets, or package discovery metadata. It also does not integrate with Illuminate\Container, it competes with it, and replacing Laravel's container would be a framework swap rather than a library adoption. The realistic fit is framework-agnostic code you own, such as extracted domain libraries, SDKs, CLI tools, or internal services that must not depend on illuminate/*. If your component only consumes dependencies, type-hint Psr\Container\ContainerInterface and let Laravel inject its own container instead.
- How do I install sanmai/di-container?
- Install it with Composer using composer require sanmai/di-container. There is no Laravel service provider to register, no config to publish, and no artisan command to run. You instantiate the container directly in your bootstrap code. Because releases are still 0.1.x, pin an exact version in composer.json rather than relying on a caret constraint.
- Which namespace do I import, DIContainer\Container or Sanmai\DI\Container?
- The README examples use DIContainer\Container and DIContainer\Builder, while internal notes reference Sanmai\DI\Container. Verify the actual namespace against the release tag you install before writing any code, for example by inspecting the package source or running a quick reflection check. A mismatch here is documentation drift you would otherwise debug against, so treat it as a signal to pin the exact version.
- What PHP versions and PSR-11 versions does sanmai/di-container support?
- The package supports PSR-11 container versions 1 and 2, so the container implements Psr\Container\ContainerInterface and its get() and has() methods. Its CI exercises PHP 8.5, and the codebase is modern PHP. Check the composer.json constraints on the tag you install if you need to support older runtimes.
- How does autowiring work with no configuration?
- The container uses reflection to inspect a class constructor and resolves each type-hinted parameter recursively, so $container->get(YourService::class) works without any registration. Objects are created once and reused, giving you singleton-like behaviour by default. Resolution is lazy, so the order in which you define services does not matter, though a later set() or bind() call overrides an earlier binding.
- How do I bind an interface or abstract class to a concrete implementation?
- Pass a map to the constructor, where the key is the interface or abstract class and the value is either a closure factory or a concrete class name. For example, LoggerInterface::class => FileLogger::class tells the container which implementation to build when that type is requested. You can also call set() or bind() later to override the binding with a closure or a preferred implementation.
- What are builder objects and when should I use them?
- A builder is a class implementing the Builder interface whose build() method returns the configured object. Because builders are themselves constructed by the container, they can take injectable dependencies, which keeps complex wiring cohesive, independently testable, and reusable. Use one when construction needs more than a constructor call, such as assembling a database connection from a config provider and a logger. The Builder template is covariant, so static analysers like PHPStan understand what build() returns.
- Does sanmai/di-container detect circular dependencies?
- Circular dependency detection is a documented omission, so a cycle in your object graph can turn into unbounded reflection recursion and end in a memory-exhaustion crash rather than a clear exception. That is a production failure mode, not just a developer convenience gap. If you adopt the package, add your own composition tests or a dependency graph check in CI that covers your registered services.
- Can I use sanmai/di-container in production or long-running workers?
- The package is BSD-3-Clause licensed and has reasonable engineering hygiene, including PSR-11 support, PHPStan at max level on fixtures, and a PHPBench suite, but it is pre-1.0 with a single maintainer and no dependent ecosystem. There is no request scope, no lazy proxies, no compile step, and no reflection cache, which matters under long-running workers such as queue consumers or Octane-style processes where resolved state persists between jobs. Pin the exact version, review each 0.1.x bump, and be prepared to fork.
- How does it compare to Illuminate\Container, PHP-DI, or Symfony's container?
- Illuminate\Container is the right choice inside Laravel because routing, middleware, events, queues, and facades all depend on it, and it also supports contextual and tag-based bindings this package deliberately omits. PHP-DI and Symfony's container offer broader feature sets such as attributes, compilation, and caching, at the cost of more configuration. sanmai/di-container trades those features for deterministic constructor-only autowiring, which suits small standalone libraries where a minimal PSR-11 implementation is all you need.