Download the PHP package sanmai/di-container without Composer

sanmai/di-container

A straightforward PSR-11 dependency injection container with automatic constructor dependency resolution.

I designed the autowiring initially for Infection's own use with focus on simplicity and zero configuration, building on the existing implementation by Maks Rafalko and Théo Fidry.

Installation

Features

• Automatically resolves class dependencies through reflection
• Objects are created once and reused
• Resolve interfaces to concrete implementations

Quick Start

The order in which you define your services is not important, as dependencies are only resolved when they are requested.

Builder Objects

Builder objects can encapsulate arbitrary complex construction logic. They can use dependency injection, which makes them cohesive, independently testable, and reusable.

The Builder interface uses a covariant template (@template-covariant T), so PHPStan correctly validates that your builder's return type matches the declared template parameter.

When you implement the Builder interface, you can simply provide the builder class name instead of a closure. The container automatically detects builder classes and handles the instantiation and build() method call.

For setting dependencies on the fly, there's a handy set() method that accepts both callables and builders.

Non-Class Service IDs

For non-class service IDs (e.g., 'app.repository'), use the bind() method or the $bindings constructor parameter:

The bind() method and $bindings parameter accept both callables and builder class names, just like set(), but without class-string type constraints on the service ID.

Pre-Built Instances

Use inject() to store objects that were created outside the container:

Design Philosophy

This container prioritizes simplicity, predictability, and architectural purity. It achieves this through:

• Predictable autowiring; there are no complex background scans or fragile naming conventions.
• Lack of surprises; the container will only resolve an interface if it can find exactly one registered factory or builder that produces a compatible implementation. It will never guess, ensuring the dependency graph is always clear, just as your day is worry-free.
• Constructor-only dependency injection; the container intentionally avoids complex features, such as property/method injection or support for variadic/composite types in constructors. This approach promotes cleaner, more testable class designs.

The container resolves interfaces using a straightforward rule: when a dependency is an interface, it looks for exactly one registered factory or a builder that produces a compatible object.

This approach allows you to wire dependencies without explicitly linking an implementation to an interface; the container connects them logically as long as the relationship is unambiguous.

The container omits circular dependency checks for simplicity, an issue that even the most minimal automatic test will immediately reveal.

Testing

Benchmarking

Runs PHPBench with OPcache and JIT enabled.