PHPackages                             sanmai/di-container - PHPackages - PHPackages  [Skip to content](#main-content)[PHPackages](/)[Directory](/)[Categories](/categories)[Trending](/trending)[Leaderboard](/leaderboard)[Changelog](/changelog)[Analyze](/analyze)[Collections](/collections)[Log in](/login)[Sign up](/register)

1. [Directory](/)
2. /
3. [PSR & Standards](/categories/psr-standards)
4. /
5. sanmai/di-container

ActiveLibrary[PSR & Standards](/categories/psr-standards)

sanmai/di-container
===================

dependency injection container with automatic constructor dependency resolution

0.1.12(3mo ago)72.7M—0.9%2[3 issues](https://github.com/sanmai/di-container/issues)[2 PRs](https://github.com/sanmai/di-container/pulls)1BSD-3-ClausePHPPHP >=8.2CI passing

Since Jul 23Pushed 1w ago1 watchersCompare

[ Source](https://github.com/sanmai/di-container)[ Packagist](https://packagist.org/packages/sanmai/di-container)[ GitHub Sponsors](https://github.com/sanmai)[ RSS](/packages/sanmai-di-container/feed)WikiDiscussions main Synced 1mo ago

READMEChangelog (10)Dependencies (10)Versions (18)Used By (1)

sanmai/di-container
===================

[](#sanmaidi-container)

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

I designed the autowiring [initially for Infection's own use](https://github.com/infection/infection/pull/2118) with focus on simplicity and zero configuration, building on the existing implementation by [Maks Rafalko](https://github.com/maks-rafalko) and [Théo Fidry](https://github.com/theofidry).

Installation
------------

[](#installation)

```
composer require sanmai/di-container
```

Features
--------

[](#features)

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

Quick Start
-----------

[](#quick-start)

```
use DIContainer\Container;

$container = new Container();

// Automatic resolution - no configuration needed
$service = $container->get(YourService::class);

// Use builder objects for complex construction, or construct the dependencies directly - your choice
$container = new Container([
    ComplexObject::class => fn(Container $container) => new ComplexObject(
        $container->get(LoggerInterface::class),
        $container->get(AnotherProvider::class)->getValue()
    ),
    DatabaseInterface::class => fn(Container $container) =>
        $container->get(DatabaseBuilder::class)->build(),
]);

// Set additional dependencies on the fly
$container->set(LoggerInterface::class, fn() => new FileLogger('debug.log'));

$service = $container->get(ServiceNeedingDatabase::class); // Auto-injects database
```

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

Builder Objects
---------------

[](#builder-objects)

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

```
use DIContainer\Builder;

/**
 * Builder that accepts injectable dependencies.
 *
 * @implements Builder
 */
class DatabaseBuilder implements Builder
{
    public function __construct(
        private readonly ConfigProvider $config,
        private readonly Logger $logger
    ) {}

    public function build(): DatabaseInterface
    {
        return new MySQLDatabase(
            $this->config->getDatabaseHost(),
            $this->config->getDatabaseCredentials(),
            $this->logger
        );
    }
}
```

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.

```
// 1. Direct class name, if the class implements DIContainer\Builder interface
$container = new Container([
    DatabaseInterface::class => DatabaseBuilder::class,
]);

// 2. Explicit closure - what will the container do under the hood
$container = new Container([
    DatabaseInterface::class => fn(Container $container) => $container->get(DatabaseBuilder::class)->build(),
]);
```

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

Non-Class Service IDs
---------------------

[](#non-class-service-ids)

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

```
// Register with a dotted ID - type validation is skipped
$container = new Container(
    values: [
        LoggerInterface::class => FileLogger::class,
    ],
    bindings: [
        'app.repository' => fn() => new CachedRepository(new DatabaseRepository()),
        'app.cache' => CacheBuilder::class,
    ]
);

// Or add bindings on the fly
$container->bind('app.mailer', fn() => new MyMailer());

// Builder classes work too
$container->bind('app.session', SessionBuilder::class);

$repository = $container->get('app.repository');
```

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
-------------------

[](#pre-built-instances)

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

```
$logger = new FileLogger('app.log');
$container->inject(LoggerInterface::class, $logger);
```

Design Philosophy
-----------------

[](#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
-------

[](#testing)

```
make -j -k
```

Benchmarking
------------

[](#benchmarking)

```
make benchmark
```

Runs [PHPBench](https://phpbench.readthedocs.io/) with OPcache and JIT enabled.

###  Health Score

52

—

FairBetter than 96% of packages

Maintenance81

Actively maintained with recent releases

Popularity50

Moderate usage in the ecosystem

Community17

Small or concentrated contributor base

Maturity47

Maturing project, gaining track record

 Bus Factor1

Top contributor holds 65.9% of commits — single point of failure

How is this calculated?**Maintenance (25%)** — Last commit recency, latest release date, and issue-to-star ratio. Uses a 2-year decay window.

**Popularity (30%)** — Total and monthly downloads, GitHub stars, and forks. Logarithmic scaling prevents top-heavy scores.

**Community (15%)** — Contributors, dependents, forks, watchers, and maintainers. Measures real ecosystem engagement.

**Maturity (30%)** — Project age, version count, PHP version support, and release stability.

###  Release Activity

Cadence

Every ~15 days

Recently: every ~6 days

Total

13

Last Release

112d ago

### Community

Maintainers

![](https://www.gravatar.com/avatar/edcb8dde95c71b1c97c3c91e57d3548795fa2014c657744fb878e2be3b5949fc?d=identicon)[sanmai](/maintainers/sanmai)

---

Top Contributors

[![sanmai](https://avatars.githubusercontent.com/u/139488?v=4)](https://github.com/sanmai "sanmai (27 commits)")[![dependabot[bot]](https://avatars.githubusercontent.com/in/29110?v=4)](https://github.com/dependabot[bot] "dependabot[bot] (12 commits)")[![Chris53897](https://avatars.githubusercontent.com/u/7104259?v=4)](https://github.com/Chris53897 "Chris53897 (1 commits)")[![Slamdunk](https://avatars.githubusercontent.com/u/152236?v=4)](https://github.com/Slamdunk "Slamdunk (1 commits)")

---

Tags

PSR-11di containerAutowiringconstructor di

###  Code Quality

TestsPHPUnit

Code StylePHP CS Fixer

### Embed Badge

![Health badge](/badges/sanmai-di-container/health.svg)

```
[![Health](https://phpackages.com/badges/sanmai-di-container/health.svg)](https://phpackages.com/packages/sanmai-di-container)
```

###  Alternatives

[devanych/di-container

Simple implementation of a PSR-11 dependency injection container

124.2k3](/packages/devanych-di-container)

PHPackages © 2026

[Directory](/)[Categories](/categories)[Trending](/trending)[Changelog](/changelog)[Analyze](/analyze)