How To Convert All Your Symfony Service Configs to Autodiscovery

Do you use Symfony autodiscovery services registration everywhere and your configs have no extra lines? Skip this post and rather read another one.

But if you have many configs with manual service registration, tagging, and autowiring, keep reading. I'll show you how you can convert them easily be new Symplify package.

I've been consulting a few Symfony e-commerce projects recently that all have service.yml. Big configs with manual service registration:

services:
    App\SomeService:
        autowire: true

    App\Controller\SomeController:
        autowire: true

    # 50 more lines...
    # 20 more files similar to this one

I already wrote How to refactor to new Dependency Injection features in Symfony 3.3, so you can read it.

What Can Go Wrong?

There are many reasons to automate this work, because there are many gotchas you have to be careful about. In each single service registration.

1. Tags

Name-only system tags can be removed thanks to autoconfigure:

 services:
-    first_command:
-        class: App\Command\FirstCommand
-        tags:
-            - { name: 'console.command' }
-
-    second_command:
-        class: App\Command\SecondCommand
-        tags: ['console.command']
+    _defaults:
+        autoconfigure: true
+
+     App\Command\:
+         resource: '../src/Command'

But you have to keep lazy-loaded commands

services:
    first_command:
        class: App\Command\FirstCommand
        tags:
          - { name: 'console.command', command: 'first' }

And tags with metadata:

services:
    App\EventListener\ExceptionListener:
        tags:
            - { name: 'kernel.event_listener', event: 'kernel.exception' }

2. Single-class Names

Service name can be often dropped:

 services:
-    app.controller:
-        class: App\SomeController
+    App\SomeController: ~

Except for classes with no namespace:

services:
    Single_Class_Name:
        class: Single_Class_Name

3. Vendor Autodiscovery

Configs are usually mixed of your code (/app or /src) and 3rd party code (/vendor):

# old config
services:
    App\SomeService: ~
    App\AnotherService: ~

    Symplify\PackageBuilder\Parameter\ParameterProvider: ~
    Symplify\PackageBuilder\FileSystem\FileGuard: ~

Seeing this you have to think about that. If not, you might accidentally apply autodiscovery everywhere:

 services:
-    App\SomeService: ~
-    App\AnotherService: ~
+    App\:
+        resource: ../src

-    Symplify\PackageBuilder\Parameter\ParameterProvider: ~
-    Symplify\PackageBuilder\FileSystem\FileGuard: ~
+    Symplify\PackageBuilder\: ~
+        resource: ../vendor/symplify/package-builder/src

Ops, the last case should not be converted - all 3rd party classes have to be explicit since they're handled by their own config/bundle in /vendor:

services:
    Symplify\PackageBuilder\Parameter\ParameterProvider: ~
    Symplify\PackageBuilder\FileSystem\FileGuard: ~

4. Exclude Obviously

When you try to autoload a class with a constructor, it's considered a service. But not all classes with constructors are services. Symfony doesn't know that unless you tell it, and it would fail with missing argument exception.

 services:
     App\:
        resource: ../src
+       exclude:
+           - ../src/Entity/*
+           - ../src/Exception/*
+           - ../src/Contract/*

Happy coding!



Do you learn from my contents or use open-souce packages like Rector every day?
Consider supporting it on GitHub Sponsors. I'd really appreciate it!