Weave Code
Container Laravel Package
internal/container
A lightweight service container for Laravel and PHP applications, offering straightforward bindings, singleton management, and dependency resolution to keep internal wiring explicit, modular, and testable. Ideal for package internals and smaller codebases that need clean, predictable object construc...
internal/container is a lightweight, PSR-11-compatible dependency injection container for Laravel/PHP internal packages. It offers a simple API for binding and resolving services, with automatic constructor injection and lazy instantiation to keep application code clean and testable.
- Singleton and transient bindings via a fluent registration API
- Auto-wiring for class dependencies
- PSR-11 interoperability for framework-agnostic resolution
- Lazy resolution with shared instance support
- Laravel integration for service providers and facades
Frequently asked questions about Container
- Is internal/container a Laravel service provider or a replacement for Illuminate\Container?
- No. internal/container is a standalone PSR-11 container, not a Laravel service provider and not a replacement for Illuminate\Container. It is architecturally compatible with Laravel because Laravel's container implements Psr\Container\ContainerInterface, but it is not additive to the framework's resolution graph. Its realistic fit is CLI tools, Artisan-adjacent scripts, queue workers, and daemons rather than the application container.
- How do I install internal/container with Composer?
- It is distributed under the Composer name internal/container, so installation is via Composer once your repository or VCS source is configured for that package. Because the vendor namespace implies internal use and there is no public ecosystem, confirm the package is reachable from your own Composer repositories and pin a specific commit. Basic use does not require registering a Laravel service provider.
- Does internal/container work alongside Laravel's container and service providers?
- Yes, via two low-effort integration patterns. In the side-by-side pattern, the CLI entrypoint builds this container and passes it explicitly while Laravel is never booted. In the bridged pattern, you register Illuminate\Container as a delegate or fallback inside this container, or use a thin PSR-11 adapter in the other direction, so framework-resolved services remain reachable. Neither pattern requires touching application service providers, but the bridge adds a resolution path you must own and test.
- Which PHP versions and PSR-11 version does internal/container support?
- The provided package metadata does not state a minimum or maximum PHP version, nor whether it targets PSR-11 1.1 or 2.0. That matters because PSR-11 2.0 changes the get() signature, and Laravel compatibility depends on the Illuminate versions you run. Treat version compatibility as a vendor audit item and test against your PHP 8.3 and 8.4 baseline before adopting.
- Can I use internal/container instead of booting Laravel for Artisan commands and queue workers?
- Yes, that is the recommended positioning: use it strictly as a CLI and worker runtime container, never as the application container. The side-by-side pattern builds this container in the entrypoint and passes it explicitly, so Laravel is never booted, which is the cleanest and lowest-blast-radius approach. Laravel web requests should keep using Illuminate\Container untouched.
- How does internal/container handle scopes and resetting singletons between queue jobs?
- The package advertises scopes, inflectors, and explicit destruction, which map directly to long-running process hygiene and are precisely where Laravel's container is weakest. However, the provided material does not document whether scopes are hierarchical, such as a request or job scope nested under a process scope, or exactly how scoped singletons are reset between jobs. Confirm the scope API and reset behavior in the source before relying on it for queue consumers.
- What does explicit destruction do in internal/container, and is it safe for shared instances?
- Explicit destruction is one of the package's advertised differentiators, but the provided material does not describe the source-level behavior. It could invoke __destruct, drop references, or run a disposal callback, and each option has different consequences for instances still referenced elsewhere in the process. Audit whether destruction is idempotent and safe for shared instances before using it in long-running daemons.
- Is internal/container production-ready given zero stars and no dependents?
- Treat it as a source-drop dependency rather than an externally validated package. It has zero stars, zero dependents, no CVE history to read, and no third-party issue tracker signal on PHP 8.3 or 8.4 edge cases, plus a single-maintainer bus factor and an internal vendor namespace. The last-release date of 2026-09-08 also looks anomalous and should be confirmed as a tagged pre-release or a metadata error before adoption.
- How does internal/container compare to PHP-DI or League\Container?
- The provided assessment does not confirm whether internal/container is a fork or derivative of PHP-DI or League\Container, so behavioral divergence is unknown. All are PSR-11-oriented containers, but internal/container is positioned narrowly for CLI and worker runtimes with advertised scopes and explicit destruction. Compare the scope API, autowiring edge cases, teardown semantics, and maintenance signals directly before choosing it over a more established container.
- Does internal/container support attributes and contextual binding, or only type-hint autowiring?
- The provided material mentions reflection-based autowiring and flags undefined behavior for union types, intersection types, and circular graphs, but it does not document attribute-based or contextual binding support. Assume type-hint autowiring is the primary path and verify the rest in the source. If you need Laravel-style contextual binding, keep Illuminate\Container for that layer.
Weaver
How can I help you explore Laravel packages today?