php-fig/container

PSR-11 Container is a PHP interface specification that defines the contract for dependency injection containers.

View on GitHub ↗Jump to charts ↓

Summary Information

Updated 9 minutes ago
Added to GitGenius on September 6th, 2026
Created on August 15th, 2016
Open Issues & Pull Requests: 6 (+0)
GitHub issues: Enabled
Number of forks: 54
Total Stargazers: 9,993 (-1)
Total Subscribers: 28 (+0)

Repository Insights (GitGenius)

Median issue/PR response: 0.5 hours
Mean response time: 0.5 hours
90th percentile: 0.5 hours
Tracked items: 1

Most active contributors

Sign in to see contributor activity.

Related repositories by overlapping contributors

Charts & Analytics

Fetching additional details & charts...

Issue Activity (beta)

Open issues: 0
New in 7 days: 0
Closed in 7 days: 0
Avg open age: N/A days
Stale 30+ days: 0
Stale 90+ days: 0

Recent activity

Opened in 7 days: 0
Closed in 7 days: 0
Comments in 7 days: 0
Events in 7 days: 0

Top labels

No label distribution available yet.

Most active issues this week

No issue events were indexed in the last 7 days.

Detailed Description

PSR-11 Container is a PHP interface specification that defines the contract for dependency injection containers.

The project addresses the fragmentation problem of incompatible container implementations across the PHP ecosystem by providing a standardized set of interfaces. Rather than implementing a container itself, it establishes abstract contracts that any container implementation can follow. This allows libraries and applications to depend on the interface rather than a specific container implementation, enabling interoperability between different dependency injection solutions.

Developers should adopt this when building libraries or frameworks that need to work with multiple container implementations without tight coupling to any single one. Projects that want to accept a container as a dependency should type-hint against these interfaces rather than concrete implementations. This is particularly valuable for middleware, plugins, and reusable packages that may be used in applications with different container choices. The project is not itself a container implementation; developers still need to choose and install a concrete implementation that adheres to these interfaces.

The project maintains a stable, minimal interface specification with no active development activity beyond maintenance of the core abstractions. Changes are infrequent and focused on preserving backward compatibility with existing implementations.