Container Laravel Package

Product Decisions This Supports

• Build vs. buy for dependency wiring: v1.2.0 closes the most common gap in lightweight containers — shared instances. singleton() lets a team standardize on one container for DB connections, HTTP/API clients, and loggers instead of hand-rolling memoized closures or global registries in each service. This makes a "use a small container, skip a full framework" decision more defensible.
• Framework/stack direction: These notes are for the Flight PHP container (flight\Container) — a standalone, framework-agnostic DI container, not a Laravel package. If the roadmap question is "do we stay on Laravel's container or adopt a portable one," this release is evidence the portable option now covers the singleton/instance-sharing baseline that Laravel's singleton()/instance() has offered for years. It does not justify migrating off Laravel's container on capability grounds alone.
• Test isolation and cost-of-ownership: Object-as-singleton registration is useful but raises a concrete PM question — there's no reset/flush mentioned for singletons between tests or requests. Scope this before committing; mutable singletons (loggers, API clients with auth state) are a classic source of flaky tests and cross-request state bleed in long-running workers (Octane/Swoole/FrankenPHP).
• Ergonomics as a delivery-cost lever: Chained set()->singleton()->set() reduces bootstrap boilerplate, which is a real onboarding and code-review cost on greenfield services. Minor, but it's the kind of thing that shortens service scaffolding.
• Roadmap signal: A minor version adding a headline DI primitive suggests the container is still filling in table-stakes features rather than maturing. Plan for continued minor releases; don't treat it as feature-frozen.

When to Consider This Package

Consider it when:

• You're building on Flight PHP, or you want a small, dependency-light PSR-style container outside a full framework (CLI tools, microservices, legacy apps being modernized incrementally).
• You need shared instances of expensive resources — DB connections, API clients, loggers — with simple constructor/class-keyed lookup.
• Your team is small and the overhead of a full framework's container, service providers, and contextual binding is unjustified.
• You're comfortable with constructor-less resolution and manual wiring; you want explicit registration over auto-wiring magic.

Look elsewhere when:

• You're on Laravel. Laravel's container already ships singleton, scoped, instance, interface binding, contextual binding, and Octane-aware lifecycle handling. Adding a second container creates two sources of truth for object lifetime — a genuine maintenance and debugging tax.
• You need scoped/request lifecycles (per-request singletons under Octane), deferred providers, or tag-based resolution — none of that is in these notes.
• You need PSR-11 conformance guarantees, auto-wiring, or compile-time container optimization (Symfony DI). Not evidenced here.
• You need documented singleton reset semantics for tests. Not evidenced here — verify before adoption.
• You require a formal support policy, LTS, or security-response commitments. A single-maintainer package with a minor-version changelog link is not that.

Assessment caveat: these notes describe only the delta from v1.1.0. Before adopting, validate the baseline: PSR-11 compliance, autowiring behavior, exception types, PHP version floor, and test-isolation story.

How to Pitch It (Stakeholders)

For executives (one line): A small, focused update to a lightweight PHP dependency-injection container that now supports shared instances of database connections, API clients, and loggers — removing a common reason teams reach for a heavier framework. Low risk, no breaking changes, relevant only if we choose a non-Laravel stack.

For engineering:

• v1.2.0 adds singleton() for both class names and pre-built objects, plus fluent chaining on the container.
• This is table-stakes DI functionality; it does not differentiate the package, and it does not exceed what Laravel's container already provides.
• It is a minor release — no deprecations or breaking changes indicated. Upgrade risk is low.
• Two open questions to answer before we standardize on it: (1) how singletons are reset between tests and long-running worker requests, and (2) whether registration by class name causes ambiguity for interface or subclass resolution.

Recommendation: Do not change course based on this release alone. If we are on Laravel, stay on Laravel's container — the overlap creates ambiguity about object lifetime and adds a second wiring convention for no capability gain. If we have a non-Laravel service or CLI tool where a minimal container is the right size, this release makes flightphp/container a viable candidate; run a short spike validating PSR-11 conformance, autowiring expectations, and test-isolation behavior before adopting.