Symfony bundles provide ready-to-use features to Symfony applications. In some cases, bundles include their own configuration and can even extend the application configuration adding new options.
These extension and configuration features are implemented via dedicated classes that extend/implement other Symfony classes. This process is well-known and not complicated, but it's a bit verbose and cumbersome. That's why in Symfony 6.1 we're introducing a simpler way to configure and extend bundles.
This is the biggest change we ever made to the bundle system and you'll love it. In Symfony 6.1, you can define the configuration and extension of a bundle directly in the main bundle class, without creating any other classes.
Let's consider a Foo
bundle that defines the following main bundle class:
1 2 3 4 5 6 7
namespace Acme\Bundle\FooBundle;
use Symfony\Component\HttpKernel\Bundle\Bundle;
class FooBundle extends Bundle
{
}
First, you need to change its base class to the new AbstractBundle
:
1 2 3 4 5 6
// ...
use Symfony\Component\HttpKernel\Bundle\AbstractBundle;
class FooBundle extends AbstractBundle
{
}
Now, do you want to define semantic configuration for this bundle? Forget about
the Configuration
class, the TreeBuilder
object, the "extension alias",
etc. Just define a configure()
method in your bundle class:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
class FooBundle extends AbstractBundle
{
// ...
public function configure(DefinitionConfigurator $definition): void
{
// loads config definition from a file
$definition->import('../config/definition.php');
// loads config definition from multiple files (when it's too long you can split it)
$definition->import('../config/definition/*.php');
// if the configuration is short, consider adding it in this class
$definition->rootNode()
->children()
->scalarNode('foo')->defaultValue('bar')->end()
->end()
;
}
}
The root key of your bundle configuration is automatically determined from your
bundle name (for FooBundle
it would be foo
). If you want to change it,
now you can simply define the following property in the bundle class:
1 2 3 4 5 6
class FooBundle extends AbstractBundle
{
protected string $extensionAlias = 'acme';
// ...
}
Finally, if you want to configure your bundle extension or to append/prepend
configuration options in the application, you no longer need to define an
Extension
class, use the XmlFileLoader
and FileLocator
to load
configuration files, etc. Define the loadExtension()
and/or
prependExtension()
methods in your bundle and that's all:
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
class FooBundle extends AbstractBundle
{
// ...
// $config is the bundle Configuration that you usually process in
// ExtensionInterface::load() but already merged and processed
public function loadExtension(array $config, ContainerConfigurator $container, ContainerBuilder $builder): void
{
$container->parameters()->set('foo', $config['foo']);
$container->import('../config/services.php');
if ('bar' === $config['foo']) {
$container->services()->set(Parser::class);
}
}
public function prependExtension(ContainerConfigurator $container, ContainerBuilder $builder): void
{
// prepend some config option
$builder->prependExtensionConfig('framework', [
'cache' => ['prefix_seed' => 'foo/bar'],
]);
// append some config option
$container->extension('framework', [
'cache' => ['prefix_seed' => 'foo/bar'],
])
// append options defined in some file (using any config format)
$container->import('../config/packages/cache.php');
}
}
We're beyond excited about this new feature! We hope you like it too and start using it as soon as you upgrade to Symfony 6.1.
Great addition, thank you
Really nice to have that all in the Bundle class. Something I was looking forward when creating: https://github.com/symfony/symfony/issues/45607 but thought they never wanted to mix them up because the Bundle class is always loaded. Does using the AbstractBundle has any performance impact?
A very welcome simplification, thanks!
If I may add a comment: in my experience many of the developers creating bundles do not take the time to learn the ins and outs of the Bundle/Configuration/Extension system and implement the minimum they can get away for their needs by means of copy-pasting the examples from the documentation. This change will surely make their life easier, but at the same time it might make it more mysterious, unless the roles of the DefinitionConfigurator, ContainerConfigurator, ContainerBuilder and $config array, and the timeline of events happening in the container build process (ie. in which order are the new bundle methods called) are clearly documented...
What's best for bundle maintainers who want to use the simplified method but support Symfony < 6.1? Should we just do things the old way until no Symfony versions before 6.1 are maintained? Or is it possible to support both in parallel?
Wahoo! Perhaps Ryan can be persuaded to update https://symfonycasts.com/screencast/symfony-bundle to use Symfony 6.1, it should be considerably shorter and easier with these improvements. Is there an example of a bundle using AbstractBundle?
It's valid to mention that these improvements are also available for bundle-less approach, in that case, you can use Symfony\Component\DependencyInjection\Extension\AbstractExtension with exactly the same methods explained here, registering this extension in your kernel class directly (especially for those apps adding their own configuration/extension)
This is awesome. However it'd be helpful if there was an example of what the imported ../config/definition.php file should contain.
@Andy you can see that in the description of the Pull Request:
https://github.com/symfony/symfony/pull/43701
Thks for this new feature !
Great improvement! Thank you 🙂