Download the PHP package milpa/container without Composer
On this page you can find all versions of the php package milpa/container. It is possible to download/install these versions without Composer. Possible dependencies are resolved automatically.
Table of contents
Download milpa/container
More information about milpa/container
Files in milpa/container
Download milpa/container
More information about milpa/container
Files in milpa/container
Vendor milpa
Package container
Short Description Reflection-autowiring PSR-11 dependency injection container for the Milpa PHP framework: lazy singleton resolution, circular-dependency detection with chain reporting, and safe optional retrieval.
License Apache-2.0
Package container
Short Description Reflection-autowiring PSR-11 dependency injection container for the Milpa PHP framework: lazy singleton resolution, circular-dependency detection with chain reporting, and safe optional retrieval.
License Apache-2.0
Please rate this library. Is it a good library?
Informations about the package container
# Milpa Container
> The **reference dependency injection container** for the Milpa PHP framework, built on **`milpa/core`**. It implements `milpa/core`'s `DIContainerInterface` with reflection autowiring, lazy singleton resolution, and circular-dependency detection that reports the full chain — on top of a PSR-11 surface backed by Symfony's `ContainerBuilder`.
[](https://github.com/getmilpa/container/actions/workflows/ci.yml)
[](https://packagist.org/packages/milpa/container)
[](https://www.php.net/)
[](LICENSE)
[](https://getmilpa.github.io/container/)
`milpa/container` is the concrete `DIContainer` behind `milpa/core`'s
`Milpa\Interfaces\Di\DIContainerInterface` — the contract every Milpa component codes
against. **No product coupling, no service-definition config format of its own**: register
services by hand, or let the container find them by reflection.
## Install
## What it guarantees, beyond the interface
`DIContainerInterface` is deliberately conservative: it documents auto-resolution of
`get()`/`has()` as a **MAY**, not a MUST — a minimal, spec-conformant implementation is
allowed to throw/return `false` for anything not explicitly registered via
`registerService()`. `resolve()` is the one method whose contract *is* auto-wiring for
every implementation.
`DIContainer` exercises that MAY. Concretely, this implementation guarantees:
- **`get()` and `has()` auto-resolve** any existing, non-abstract, non-interface class
whose constructor dependencies are themselves resolvable, recursively — not just
identifiers registered via `registerService()`.
- **Auto-resolved classes are cached as singletons** on first resolution: later `get()`
calls for the same identifier return the same instance, unless `resolve()` was called
directly with `$singleton = false`.
- **Circular dependencies are detected and reported with the full chain** — `A` needs `B`
needs `A`, directly or transitively, throws `CircularDependencyException` with every
class name in the cycle, not just a generic "circular dependency" message.
- **`tryGet()` never throws** — it returns `null` for anything unregistered and
unresolvable, instead of propagating `ServiceNotFoundException` or
`ContainerResolutionException`.
- **Non-resolvable classes are cached as such** (interfaces, abstract classes, classes
with unresolvable constructor parameters), so repeated lookups don't re-run reflection.
If you need one of these guarantees, depend on `DIContainer` (or its documented behavior)
directly — `DIContainerInterface` alone does not promise them.
## Quick example
Circular dependencies fail loudly, with the chain that caused them:
## What lives where
| Layer | Package | Owns |
|-------|---------|------|
| Contracts | `milpa/core` | `DIContainerInterface` (extends PSR-11 `ContainerInterface`), `ServiceNotFoundException`, `ContainerResolutionException`, `CircularDependencyException` — the seam, not the engine. |
| **Implementation** | **`milpa/container`** (this package) | The concrete `DIContainer`: reflection autowiring, singleton caching, circular-dependency detection, and safe (`tryGet()`) retrieval on top of Symfony's `ContainerBuilder`. |
| Your app | your host / plugins | Wiring decisions — which services to register explicitly vs. leave to autowiring, and when to call `compileContainer()`. |
## Requirements
- PHP **≥ 8.3**
- [`milpa/core`](https://packagist.org/packages/milpa/core) **^0.6**
- [`psr/container`](https://packagist.org/packages/psr/container) **^2.0**
- [`symfony/dependency-injection`](https://packagist.org/packages/symfony/dependency-injection) **^7.0**
## Documentation
**Full API reference: [getmilpa.github.io/container](https://getmilpa.github.io/container/)** — generated
straight from the source DocBlocks and dressed with the Milpa design system.
## Contributing
Contributions are welcome — see [CONTRIBUTING.md](CONTRIBUTING.md). Please report security
issues via [SECURITY.md](SECURITY.md), and note that this project follows a
[Code of Conduct](CODE_OF_CONDUCT.md).
## License
[Apache-2.0](LICENSE) © Rodrigo Vicente - TeamX Agency.
---
Milpa is designed, built, and maintained by **[Rodrigo Vicente - TeamX Agency](https://teamx.agency/?utm_source=github&utm_medium=readme&utm_campaign=milpa&utm_content=container)**.
All versions of container with dependencies
PHP Build Version
Package Version
Requires
php Version
>=8.3
milpa/core Version >=0.6.2 <1.0
psr/container Version ^2.0
symfony/dependency-injection Version ^7.0
milpa/core Version >=0.6.2 <1.0
psr/container Version ^2.0
symfony/dependency-injection Version ^7.0
The package milpa/container contains the following files
Loading the files please wait ...