This PR aims to simplify DI extension/configuration definitions at the Bundle level (based on@Nyholm#40259 (comment))

Currently, the services and configuration definitions have to deal with some conventions:

• Create theDependencyInjection/ directory
• Create theDependencyInjection/Configuration.php class to define the bundle config.
• Create theDependencyInjection/FooExtension.php extension class and extend fromExtension
• In theExtensionInterface::load() method to implement we have to:
  • Process the bundle configuration yourselfConfiguration,Processor, etc.
  • Create the specific*FileLoader &FileLocator instances to import services definition (have to deal with bundle path)
• Prepend/append configs for other extensions requires implementingPrependExtensionInterface.
• RedefineBundle::$name to change the extension alias.

Although it may not be a big problem to follow all these conventions (indeed, we have been doing it for years) it's true that there are limitations and it requires extra work to achieve them.

Note: The following improvements don't pretend to deprecate the actual convention (at least so far) but simplify it with some benefits.

To start using the following improvements your bundle must extend from the new abstract classAbstractBundle to autoconfigure all hooks and make this possible inside a bundle class.

The first improvement offers the possibility to configure your bundle DI extension within the bundle class itself usingloadExtension() method and the fluentContainerConfigurator helper:

class FooBundleextends AbstractBundle{publicfunctionloadExtension(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);        }    }}

This new methodloadExtension() (a same goal thatExtensionInterface::load()) contains now all new benefits you currently love for service definition/import/etc. Keep in mind that this configurator still works with a temporal container, so you can't access any extension config at this point (as before). And, the$config argument is the bundle'sConfiguration that you usually process onExtensionInterface::load() but here it's given to you already merged and processed (ready to use).

The next improvement comes when you want to prepend/append an extension config before all extensions are loaded & merged, then use theprependExtension() method:

class FooBundleextends AbstractBundle{publicfunctionprependExtension(ContainerConfigurator$container,ContainerBuilder$builder):void    {// prepend$builder->prependExtensionConfig('framework', ['cache' => ['prefix_seed' =>'foo/bar'],        ]);// append$container->extension('framework', ['cache' => ['prefix_seed' =>'foo/bar'],        ])// append from file$container->import('../config/packages/cache.php');    }}

This is the improved alternative toPrependExtensionInterface that you normally implement on extension classes. But using this method has bonus points, you can now use theContainerConfigurator to append an extension config from an external file in any format (including the new PHP fluent-config feature).

Another improvement is aboutConfiguration definition. Here you can manage it directly within the bundle class using theconfigure() method with new possibilities:

class FooBundleextends AbstractBundle{publicfunctionconfigure(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');// defines config directly when it's short$definition->rootNode()            ->children()                ->scalarNode('foo')->defaultValue('bar')->end()            ->end()        ;    }}

You don't have to create theTreeBuilder instance yourself anymore and remember the proper extension alias. Instead, you will use a newDefinitionConfigurator with the possibility to import configuration definitions from an external PHP file, and this config file can now be placed outside thesrc/ directory of the bundle if desired:

// Acme/FooBundle/config/definition.phpuseSymfony\Component\Config\Definition\Configurator\DefinitionConfigurator;returnstaticfunction (DefinitionConfigurator$definition) {$definition->rootNode()        ->children()            ->scalarNode('foo')->defaultValue('bar')->end()        ->end()    ;};

And why not, you could also split your definition into several files if it's too long, or simply define the config directly in the method if it's short.

Last but not least you can change the extension alias by redefining a new property that now belongs to theAbstractBundle class:

class AcmeFooBundleextends AbstractBundle{protectedstring$extensionAlias ='foo';// alias used during the extension config loading// ...}

The default alias will be determined from your bundle name (in this caseacme_foo), so the new way allows you to change that alias without either touching your bundle name or overriding any method.

Note: The same feature has been implemented in a newAbstractExtension class for those applications applying the bundle-less approach and want to define configuration through an extension.

Combining all these benefits I believe we gain a more simplified bundle structure while decreasing the learning curve.