How to Import Configuration Files/Resources

Edit this page

Tip

In this section, service configuration files are referred to as resources. While most configuration resources are files (e.g. YAML, XML, PHP), Symfony is able to load configuration from anywhere (e.g. a database or even via an external web service).

The service container is built using a single configuration resource (config/services.yaml by default). This gives you absolute flexibility over the services in your application.

External service configuration can be imported in two different ways. The first method, commonly used to import other resources, is via the imports directive. The second method, using dependency injection extensions, is used by third-party bundles to load the configuration. Read on to learn more about both methods.

Importing Configuration with imports

By default, service configuration lives in config/services.yaml. But if that file becomes large, you're free to organize into multiple files. Suppose you decided to move some configuration to a new file:

1
2
3
4
5
6
# config/services/mailer.yaml
parameters:
    # ... some parameters

services:
    # ... some services

To import this file, use the imports key from any other file and pass either a relative or absolute path to the imported file:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
# config/services.yaml
imports:
    - { resource: services/mailer.yaml }
    # If you want to import a whole directory:
    - { resource: services/ }
services:
    _defaults:
        autowire: true
        autoconfigure: true

    App\:
        resource: '../src/*'

    # ...

When loading a configuration file, Symfony first processes all imported files in the order they are listed under the imports key. After all imports are processed, it then processes the parameters and services defined directly in the current file. In practice, this means that later definitions override earlier ones.

For example, if you use the default services.yaml configuration as in the above example, your main config/services.yaml file uses the App\ namespace to auto-discover services and loads them after all imported files. If an imported file (e.g. config/services/mailer.yaml) defines a service that is also auto-discovered, the definition from services.yaml will take precedence.

To make sure your specific service definitions are not overridden by auto-discovery, consider one of the following strategies:

  1. Exclude services from auto-discovery
  2. Override services in the same file
  3. Control import order

Exclude services from auto-discovery

Adjust the App\ definition to use the exclude option. This prevents Symfony from auto-registering classes that are defined manually elsewhere:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
# config/services.yaml
   imports:
       - { resource: services/mailer.yaml }
       # ... other imports

   services:
       _defaults:
           autowire: true
           autoconfigure: true

       App\:
           resource: '../src/*'
           exclude:
               - '../src/Mailer/'
               - '../src/SpecificClass.php'

.. code-block:: xml

    <!-- config/services.xml -->
    <?xml version="1.0" encoding="UTF-8" ?>
    <container xmlns="http://symfony.com/schema/dic/services"
        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xsi:schemaLocation="http://symfony.com/schema/dic/services
            https://symfony.com/schema/dic/services/services-1.0.xsd">

        <imports>
            <import resource="services/mailer.xml"/>
            <!-- If you want to import a whole directory: -->
            <import resource="services/"/>
        </imports>

        <services>
            <defaults autowire="true" autoconfigure="true"/>

            <prototype namespace="App\" resource="../src/*">
                <exclude>../src/Mailer/</exclude>
                <exclude>../src/SpecificClass.php</exclude>
            </prototype>

            <!-- ... -->
        </services>
    </container>

.. code-block:: php

    // config/services.php
    namespace Symfony\Component\DependencyInjection\Loader\Configurator;

    return function(ContainerConfigurator $container): void {
        $container->import('services/mailer.php');
        // If you want to import a whole directory:
        $container->import('services/');

        $services = $container->services()
            ->defaults()
                ->autowire()
                ->autoconfigure()
        ;

        $services->load('App\\', '../src/*')
            ->exclude([
                '../src/Mailer/',
                '../src/SpecificClass.php',
            ]);
    };

Override services in the same file

You can define specific services after the App\ auto-discovery block in the same file. These later definitions will override the auto-registered ones:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
# config/services.yaml
   services:
       _defaults:
           autowire: true
           autoconfigure: true

       App\:
           resource: '../src/*'

       App\Mailer\MyMailer:
           arguments: ['%env(MAILER_DSN)%']

.. code-block:: xml

    <!-- config/services.xml -->
    <?xml version="1.0" encoding="UTF-8" ?>
    <container xmlns="http://symfony.com/schema/dic/services"
        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xsi:schemaLocation="http://symfony.com/schema/dic/services
            https://symfony.com/schema/dic/services/services-1.0.xsd">

        <imports>
            <import resource="services/mailer.xml"/>
            <!-- If you want to import a whole directory: -->
            <import resource="services/"/>
        </imports>

        <services>
            <defaults autowire="true" autoconfigure="true"/>

            <prototype namespace="App\" resource="../src/*"/>

            <service id="App\Mailer\MyMailer">
                <argument>%env(MAILER_DSN)%</argument>
            </service>

            <!-- ... -->
        </services>
    </container>

.. code-block:: php

    // config/services.php
    namespace Symfony\Component\DependencyInjection\Loader\Configurator;

    return function(ContainerConfigurator $container): void {
        $services = $container->services()
            ->defaults()
                ->autowire()
                ->autoconfigure();

        $services->load('App\\', '../src/*');

        $services->set(App\Mailer\MyMailer::class)
            ->arg(0, '%env(MAILER_DSN)%');
    };

Control import order

Move the App\ auto-discovery config to a separate file and import it before more specific service files. This way, specific service definitions can override the auto-discovered ones.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
# config/services/autodiscovery.yaml
services:
    _defaults:
        autowire: true
        autoconfigure: true

    App\:
        resource: '../../src/*'
        exclude:
            - '../../src/Mailer/'

# config/services/mailer.yaml
services:
    App\Mailer\SpecificMailer:
        # ... custom configuration

# config/services.yaml
imports:
    - { resource: services/autodiscovery.yaml }
    - { resource: services/mailer.yaml }
    - { resource: services/ }

services:
    # definitions here override anything from the imports above
    # consider keeping most definitions inside imported files

Note

Due to the way in which parameters are resolved, you cannot use them to build paths in imports dynamically. This means that something like the following does not work:

1
2
3
# config/services.yaml
imports:
    - { resource: '%kernel.project_dir%/somefile.yaml' }

Importing Configuration via Container Extensions

Third-party bundle container configuration, including Symfony core services, are usually loaded using another method: a container extension.

Internally, each bundle defines its services in files like you've seen so far. However, these files aren't imported using the import directive. Instead, bundles use a dependency injection extension to load the files automatically. As soon as you enable a bundle, its extension is called, which is able to load service configuration files.

In fact, each configuration file in config/packages/ is passed to the extension of its related bundle - e.g. FrameworkBundle or TwigBundle - and used to configure those services further.

This work, including the code samples, is licensed under a Creative Commons BY-SA 3.0 license.
TOC
    Version