New in Symfony 4.4: Dependency Injection Improvements (Part 1)

Dumping the Container in One File

Contributed by
Nicolas Grekas
in #32581.

Originally, Symfony container was compiled and dumped into a big PHP file. Then we changed it to allow dumping each service into its own small PHP file. In Symfony 4.4 we added a new configuration option to allow dumping the container again into a big single file.

This is enabled by default for all new Symfony applications, but you can also enable it for your existing applications inside the src/Kernel.php file:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
class Kernel extends BaseKernel
{
    // ...

    protected function configureContainer(ContainerBuilder $container, LoaderInterface $loader): void
    {
        // ...

        $container->setParameter('container.dumper.inline_factories', true);

        // ...
    }
}

Ignore Errors when Importing Files

Contributed by
Andrej Hudec
in #31310.

When importing configuration files, you can use the ignore_errors: true option to silently ignore any missing files. However, this option also ignores files which exist but contain syntax errors. In Symfony 4.4 we've added a new value for this option so you ignore only missing files and not files with syntax errors:

1
2
3
imports:
    # this will show an error if 'parameters.yaml' exists but contains syntax errors
    - { resource: 'parameters.yaml', ignore_errors: 'not_found' }

Allow Using Base64url Values in Env Vars

Contributed by
Nicolas Grekas
in #34014.

Using standard Base64 in URL requires encoding of +, / and = characters. That's why the RFC 4648 defines a Base64 variant called Base64url which is safe for URLs and file names. Base64url replaces + by - and / by _ (and makes the trailing = optional).

In Symfony 4.4, we've improved the base64 env var processor to also allow parsing base64url values. You don't have to change anything in your code because Symfony can detect base64url values automatically and parse them for you.

Allow Binding Tagged Services

Contributed by
Grégoire Pineau
in #33623.

Binding arguments by name or type allows to inject services and parameters based on the name and/or type of the service constructor arguments. In Symfony 4.4 you can also inject iterable and tagged services.

In the following example, the _instanceof config adds a tag to any services whose classes implement the given interface and the _defaults.bind config injects all those services in any iterable $rules constructor argument:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
# config/services.yaml
services:
    _instanceof:
        App\Foo\Rule\RuleInterface:
            tags: ['app.foo.rule']

    _defaults:
        bind:
            iterable $rules: !tagged_iterator app.foo.rule

    # ...

New in Symfony 4.4: Dependency Injection Improvements (Part 1) symfony.com/blog/new-in-symfony-4-4-dependency-injection-improvements-part-1

Tweet this

Comments

I imagine that the changes in dumping the container in split files or not is related to performances: what are the drawbacks of both approaches?
I got the answer from the related PR:
> We demonstrated in the past that loading a set of smaller files is faster than loading a single big container file. The drawback that @lyrixx experienced is found on workers: because they are long-running, they are more likely to be affected by the removal of one of those files. This doesn't happen for requests that reload everything all the time.
>
>What is unknown is how PHP 7.4 will change the situation regarding performance. With preloading, a single big file can, in theory, be similarly fast or faster. But anyway, we're not going to support only PHP 7.4. If that's confirmed, we'll be able to have a recipe that sets this param to true on PHP 7.4, and drop that in Symfony 6.
For 5.0.0, why set the default to one big file? Has it been confirmed that the big file is not slower on 7.2 or 7.3? I could see doing that in development but it seems to default to one big file in production as well. Just seems strange.
From what I understood, this is not the default in "new apps". It might be considered if php 7.4 (as symfony 6 will probably be based on that or php 8 ?) AND preloading is activated.

For now, it's not the default.
Perhaps it was not intended that way but if you create a new 4.4.0 or 5.5.0 project then a single file container is generated. I happen to be using 7.3.
Indeed : https://github.com/symfony/recipes/blob/master/symfony/framework-bundle/4.2/src/Kernel.php#L36-L37
Login with SymfonyConnect to post a comment