psr/container

psr/container defines PSR-11, the PHP-FIG standard interface for dependency injection containers. It ships no implementation of its own — just three interfaces (ContainerInterface, ContainerExceptionInterface, NotFoundExceptionInterface) that any DI container or service locator can implement so application code can type-hint against a common, interoperable contract instead of a specific framework’s container class.

What You Get

• ContainerInterface with get(string $id) and has(string $id) methods for retrieving and checking service entries
• NotFoundExceptionInterface for signaling an unknown container entry was requested
• ContainerExceptionInterface as the base exception type for any other container-level error
• A tiny, dependency-free package (php: >=7.4.0 only) safe to require from any library regardless of the app’s chosen DI container

Common Use Cases

• Type-hinting a container parameter in a reusable library so it works with any PSR-11 container the consuming app provides
• Implementing a custom or framework-specific DI container that needs to interoperate with the broader PHP ecosystem
• Middleware, routers, and plugin systems that pull handlers/services out of an injected container without a hard framework dependency
• Testing code by swapping in a minimal in-memory PSR-11 container implementation instead of a full framework container

Under The Hood

Architecture: The entire package is three interface files under src/ with no logic — ContainerInterface declares get()/has(), and the two exception interfaces extend PHP’s Throwable contract, giving implementers a shared exception hierarchy to catch against. Tech Stack: Plain PHP 7.4+ with PSR-4 autoloading (Psr\Container\ → src/), zero runtime dependencies, and no build step — it’s a pure specification package published on Packagist. Code Quality: There is no implementation code to test, so the repository’s quality bar is really about interface stability and clarity of doc comments; the interfaces have been stable since PSR-11 was accepted and see very few changes, which is itself the desired property for a standards package. API Design: This is as minimal as an API can be — two methods total (get, has) — deliberately so, since the entire value proposition of PSR-11 is a contract small enough that every DI container implementation can adopt it without friction.