Container Wrapper Bundle Laravel Package

Getting Started

This bundle is deprecated and archived (last release October 2015). You will only encounter it in legacy Symfony 2.x codebases. Before adopting anything, confirm the project already depends on it — do not introduce it into a new application.

Minimal steps in an existing legacy project:

1. Ensure the dependency is present and pinned:

   composer require liip/container-wrapper-bundle
   

2. Register the bundle in app/AppKernel.php:

   new Liip\ContainerWrapperBundle\LiipContainerWrapperBundle(),
   

3. Open the bundle's README.md on GitHub first — configuration keys are version-specific and there is no maintained docs site.
4. Start with the canonical use case: a service that needs to lazily reach a handful of other services (to avoid circular references or heavy constructor wiring) but should not receive the raw ContainerInterface.

The first thing to verify is which class the wrapper exposes and what its get() signature looks like in your pinned version; treat the config block as something to copy from the README rather than guess.

Implementation Patterns

Allowlist wrapper instead of raw container. The core pattern is: define a wrapper service that exposes a restricted set of service IDs, then inject that wrapper where you would otherwise inject service_container. The service only sees the IDs you granted.

Breaking circular dependencies. When A needs B and B needs A, inject the wrapper into one side and resolve lazily:

class A
{
    public function __construct(private $services) {}
    public function doWork()
    {
        $this->services->get('b')->handle();
    }
}

This keeps the constructor light and defers instantiation until the call site.

Decoupling from Symfony. Because the wrapper is your own type (not ContainerInterface), callers depend on a narrow surface. That makes unit tests trivial: pass a stub object with a get() that returns fakes, with no container booted.

Scoping per feature/bounded context. Create one wrapper per module (e.g. billing_services, reporting_services) so each wrapper's allowlist documents the module's external dependencies. This doubles as an architecture check during code review.

Testing integration. In functional tests, override the wrapper definition with a test double that returns mocked collaborators, avoiding full container boot for the service under test.

Gotchas and Tips

• Deprecation is the headline. Symfony's native ServiceLocator, ServiceSubscriberInterface, and PSR-11 ContainerInterface cover the same ground with first-class support and autowiring. Any new work should use those instead; treat this bundle as migration debt.
• Version drift. Archived in 2015 means no PHP 7/8 or Symfony 3/4+ compatibility. If you are upgrading Symfony, this bundle will be one of the blockers — plan to replace it before or during the upgrade.
• Silent service-not-found failures. Wrappers typically throw a generic exception when a service ID is not in the allowlist. Add the ID to config rather than widening to the raw container; the moment you inject service_container "just to fix it," you have defeated the bundle's purpose.
• Config caching. In legacy Symfony, config changes require a cache clear (app/console cache:clear). If a newly allowed service "isn't there," you are almost certainly running a stale container.
• Debugging. Use app/console container:debug to confirm the wrapper service ID and its arguments. Log inside the wrapper's get() when tracing why a service resolves unexpectedly.
• Extension point. The wrapper is a plain service; you can decorate it or subclass it to add logging, metrics, or lazy-proxy behavior. Do this rather than editing vendor code.
• Security posture. Keep allowlists minimal and reviewed. The whole point is that a compromised or misused service cannot reach arbitrary container entries — do not re-export the container through the wrapper.