Container Laravel Package

Product Decisions This Supports

• Framework selection (micro-framework vs. full-stack): If your team is evaluating FastD as a lightweight PHP micro-framework, the container is the load-bearing architectural piece — it determines how services are wired, how testable the codebase is, and how much boilerplate your engineers own. This package is the thing you're actually betting on when you bet on FastD.
• Build vs. buy on dependency injection: A ready-made, PSR-11-compatible container means you don't spend sprint capacity writing service resolution, lazy loading, or config-driven bindings. That's a real, if small, engineering-cost decision.
• Service architecture standards: Whether to standardize on constructor injection, singleton vs. factory bindings, and config-driven service definitions. These are conventions that propagate across every service in the codebase, so the container choice effectively sets them.
• Dependency and supply-chain policy: With 3 stars, 0 dependents, and no visible downstream adoption, adopting this is a procurement/vendor-risk decision as much as a technical one. It's a useful test case for how your org vets low-adoption infrastructure dependencies.
• Not a roadmap or differentiator decision. This is plumbing. It will not move activation, retention, or revenue. Treat it as an infrastructure line item, not a product bet.

When to Consider This Package

Consider it if:

• You are already committed to (or actively piloting) FastD and need the container that the framework expects.
• You need a minimal PSR-11 container for a small internal service, CLI tool, or worker where Symfony DI's configuration and compilation overhead is disproportionate.
• Your service graph is small, autowiring needs are simple, and the team is comfortable reading the container source when documentation runs out.
• You want a low-cost spike: MIT licensed, small surface area, easy to throw away.

Look elsewhere if:

• You are on Laravel. Laravel already ships illuminate/container — zero marginal cost, best-in-class documentation, contextual binding, interface binding, and a massive hiring and Stack Overflow ecosystem. Adding a second container here is pure downside; this is the strongest "no" signal for a Laravel-context evaluation.
• You are on Symfony. The DI component gives you a compiled container, autowiring, tagging, service decoration, and lazy proxies. You would be trading a mature, profiled system for a much thinner one.
• You need framework-agnostic DI with community depth. PHP-DI or League\Container offer comparable PSR-11 ergonomics with substantially larger user bases and answer corpora.
• You need vendor assurance. No SLA, no commercial support, single-maintainer risk, and effectively no ecosystem to hire against. For anything revenue-bearing or long-lived, that is a hard blocker.
• Metadata caution: the listed last release (2026-10-27) is a future date relative to normal release cadence, which suggests the registry metadata is unreliable. Do not treat the release timestamp as a maintenance signal without verifying the repository directly.

How to Pitch It (Stakeholders)

To executives: This is a small, MIT-licensed dependency-injection container from the FastD micro-framework ecosystem. It is free, technically sound, and low-risk to trial in a non-critical internal service. It is not something to standardize on: three GitHub stars and zero dependent packages mean no community, no commercial support, and a single-maintainer bus factor. My recommendation is to treat it as a prototype-only option and default to the container that ships with whichever framework we've already chosen — that choice has a lower total cost of ownership and a far deeper hiring pool. If we adopt it, we isolate it behind PSR-11 interfaces so it stays replaceable.

To engineering: It's PSR-11 compliant, so the interface is the contract — wire it in one place at the composition root, never let it leak into domain code, and swapping to Symfony DI or PHP-DI later becomes a contained change rather than a rewrite. Adopt only if FastD is already the framework decision; otherwise reach for the framework's native container first.