Autowiring Bundle Laravel Package

Getting Started

This bundle is a pre-Symfony 2.8 autowiring shim: it let you stop hand-declaring constructor arguments in services.yml by scanning service classes and injecting type-hinted dependencies automatically. It is archived (last release Feb 2016) and effectively superseded by native Symfony autowiring, so treat it as legacy-maintenance only — you are reading this because it is already in a codebase, not because you should add it.

Minimal steps to get it running in the project where it already lives:

1. Confirm the pinned version in composer.json and that your Symfony/PHP versions match what the bundle supported (Symfony 2.x era, PHP 5.x). Do not attempt to install it on a modern Symfony — the compiler pass and annotation reader usage will not survive.
2. Register the bundle in app/AppKernel.php:

   new Kutny\AutowiringBundle\KutnyAutowiringBundle(),
   

3. Enable it under app/config/config.yml. Verify the exact key by opening DependencyInjection/Configuration.php in the bundle — the config surface is small and the README is the only other source of truth.
4. Pick one service and let autowiring resolve it instead of listing arguments. The typical first use case is a service with a single type-hinted constructor dependency you were previously wiring by hand:

   class InvoiceMailer
   {
       /** @var \Swift_Mailer */
       private $mailer;
   
       public function __construct(\Swift_Mailer $mailer)
       {
           $this->mailer = $mailer;
       }
   }
   

   Define it with no arguments: key and let the bundle fill in $mailer from the container.
5. Clear the cache and inspect the result: app/console cache:clear && app/console debug:container InvoiceMailer. If the argument shows up in the compiled definition, autowiring is active for that service.

Where to look first when something does not wire: the bundle's compiler pass (usually DependencyInjection/Compiler/...Pass.php) is the entire mechanism; the Autowiring service is the resolver. Read those two before the README — the README is thin.

Implementation Patterns

Constructor autowiring is the primary path. Any service whose constructor arguments are all class type-hints can be defined with no arguments at all. Keep constructors free of scalars, arrays, and optional configuration values so they stay autowirable; push configuration into explicit setter calls or a separate config object.

Interface to implementation binding. When a constructor type-hints an interface, autowiring cannot pick an implementation on its own. Keep the explicit arguments: entry for that one parameter and autowire the rest — or, if the bundle version supports it, declare the concrete service id to match the type-hint's FQCN so resolution succeeds by convention:

services:
    Acme\Billing\GatewayInterface:
        alias: acme.billing.gateway

Verify alias support against the resolver before relying on it; older builds resolve strictly by class name.

Leave existing definitions alone where they already work. The bundle does not remove hand-written definitions; it only fills gaps. A pragmatic migration is to autowire new services at the leaves of the dependency graph and leave core services explicitly defined, so a broken resolver only affects new code.

Controllers as services. If controllers are registered as services, constructor autowiring removes the boilerplate of listing every repository and manager. This is where the bundle buys the most day-to-day value in a legacy app.

Overlays for tests. Because autowiring reads the container's definitions, tests that override a service (a mock Swift_Mailer, a fake repository) work exactly as they would with explicit wiring — set the definition in the test container and the class under test receives the mock. No annotation changes needed.

Annotation-driven injection for setters and properties. Where the bundle provides an @Autowired annotation, use it sparingly — setter injection for optional collaborators, property injection never (it hides dependencies and breaks in unit tests without a container). Prefer constructor injection for anything you intend to test in isolation.

Migration pattern to native autowiring. Since native Symfony autowiring covers the same ground, the real implementation pattern for 2016-era bundles is a staged handoff: flip services: _defaults: autowire: true (or per-service autowire: true) in Symfony 2.8+, delete the bundle registration, and delete @Autowired annotations as you touch each class. Type-hinted constructors require no changes at all — which is exactly the payoff of having used this bundle correctly.

Gotchas and Tips

• It is archived with zero dependents. There are no upstream fixes, no security response, and no compatibility work for modern Symfony. Do not build new features on it; schedule removal. Native autowiring (Symfony 2.8+) does everything this does, better, and is maintained.
• Annotation reading requires doctrine/annotations and correct annotation autoloading. If injection silently stops working, that dependency and its cache are the first suspects — clear both the Symfony cache and any annotation cache directory.
• Scalars and arrays are never autowired. A nullable or defaulted argument may be skipped, but a required scalar will fail at compile time with an unhelpful "cannot autowire" style error. Always declare scalar arguments explicitly.
• Strict class-name resolution. Older resolver implementations match the exact FQCN of the parameter's type. Subclass type-hints, aliases, and parent-class hints can miss. When a dependency "should" resolve but does not, log the type-hint FQCN and grep the compiled container for that exact id.
• Circular dependencies fail hard. Constructor autowiring makes cycles easier to create accidentally. Break them with setter injection, a lazy proxy, or an event — the resolver will throw rather than silently produce a half-built object, which is the good outcome.
• Compiler pass ordering matters. If another bundle's compiler pass adds or rewrites definitions after autowiring runs, those definitions won't be autowired. Check pass priority in the bundle's KutnyAutowiringBundle::build() and raise it if you need to autowire services registered late.
• Debugging is container archaeology. debug:container <id> shows the resolved arguments; --show-private is needed for non-public services in some versions. When debugging, dump the compiled container (var/cache/dev/appDevDebugProjectContainer.php) and read the constructor call directly.
• Caching hides changes. Definition and annotation changes require a cache clear before they take effect in dev. If a change "doesn't apply," clear the cache before investigating further.
• Extension points are minimal: the compiler pass, the autowiring service, and (if present) the annotation class. You can subclass the annotation or decorate the resolver, but given the archived status, prefer not to extend — anything custom becomes permanent migration debt.
• Do not mix with native autowiring in the same container. Enabling both can cause double-resolution or confusing errors where native wiring is disabled by the bundle pass. Pick one per service and finish the migration.