Dumping the Container in One File
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
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
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
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
# ...
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:
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