…h file loaders (yceruto)This PR was merged into the 7.1 branch.Discussion----------[DependencyInjection] Prepending extension configs with file loaders| Q             | A| ------------- | ---| Branch?       | 7.1| Bug fix?      | no| New feature?  | yes| Deprecations? | no| Issues        |Fix#52789| License       | MIT#52636 continuation.This is another try to simplify even more the prepending extension config strategy for Bundles and Extensions.Feature: "Import and prepend an extension configuration from an external YAML, XML or PHP file"> Useful when you need to pre-configure some functionalities in your app, such as mapping some DBAL types provided by your bundle, or simply pre-configuring some default values automatically when your bundle is installed, without losing the ability to override them if desired in userland.```phpclass AcmeFooBundle extends AbstractBundle{    public function prependExtension(ContainerConfigurator $container, ContainerBuilder $builder): void    {        // Before        $config = Yaml::parse(file_get_contents(__DIR__.'/../config/doctrine.yaml'));        $builder->prependExtensionConfig('doctrine', $config['doctrine']);        // After        $container->import('../config/doctrine.yaml');    }}```The "Before" section is limited to importing/parsing this kind of configuration by hand; it doesn't support features like `when@env`, recursive importing, or defining parameters/services in the same file. Further, you can't simply use `ContainerConfigurator::import()` or any `*FileLoader::load()` here, as they will append the extension config instead of prepending it, defeating the prepend method purpose and breaking your app's config strategy. Thus, you are forced to use `$builder->prependExtensionConfig()` as the only way.> This is because if you append any extension config using `$container->import()`, then you won't be able to change that config in your app as it's merged with priority. If anyone is doing that currently, it shouldn't be intentional.Therefore, the "After" proposal changes that behavior for `$container->import()`. *Now, all extension configurations encountered in your external file will be prepended instead. BUT, this will only happen here, at this moment, during the `prependExtension()` method.*Of course, this little behavior change is a "BC break". However, it is a behavior that makes more sense than the previous one, enabling the usage of `ContainerConfigurator::import()` here, which was previously ineffective.This capability is also available for `YamlFileLoader`, `XmlFileLoader` and `PhpFileLoader` through a new boolean constructor argument:```phpclass AcmeFooBundle extends AbstractBundle{    public function prependExtension(ContainerConfigurator $container, ContainerBuilder $builder): void    {        // Before        // - It can't be used for prepending config purposes        // After        $loader = new YamlFileLoader($builder, new FileLocator(__DIR__.'/../config/'), prepend: true);        $loader->load('doctrine.yaml'); // now it prepends extension configs as default behavior        // or        $loader->import('prepend/*.yaml');    }}```These changes only affect the loading strategy for extension configs; everything else keeps working as before.Cheers!Commits-------6ffd706 prepend extension configs with file loaders

…h file loaders (yceruto)This PR was merged into the 7.1 branch.Discussion----------[DependencyInjection] Prepending extension configs with file loaders| Q             | A| ------------- | ---| Branch?       | 7.1| Bug fix?      | no| New feature?  | yes| Deprecations? | no| Issues        | Fix #52789| License       | MITsymfony/symfony#52636 continuation.This is another try to simplify even more the prepending extension config strategy for Bundles and Extensions.Feature: "Import and prepend an extension configuration from an external YAML, XML or PHP file"> Useful when you need to pre-configure some functionalities in your app, such as mapping some DBAL types provided by your bundle, or simply pre-configuring some default values automatically when your bundle is installed, without losing the ability to override them if desired in userland.```phpclass AcmeFooBundle extends AbstractBundle{    public function prependExtension(ContainerConfigurator $container, ContainerBuilder $builder): void    {        // Before        $config = Yaml::parse(file_get_contents(__DIR__.'/../config/doctrine.yaml'));        $builder->prependExtensionConfig('doctrine', $config['doctrine']);        // After        $container->import('../config/doctrine.yaml');    }}```The "Before" section is limited to importing/parsing this kind of configuration by hand; it doesn't support features like `when@env`, recursive importing, or defining parameters/services in the same file. Further, you can't simply use `ContainerConfigurator::import()` or any `*FileLoader::load()` here, as they will append the extension config instead of prepending it, defeating the prepend method purpose and breaking your app's config strategy. Thus, you are forced to use `$builder->prependExtensionConfig()` as the only way.> This is because if you append any extension config using `$container->import()`, then you won't be able to change that config in your app as it's merged with priority. If anyone is doing that currently, it shouldn't be intentional.Therefore, the "After" proposal changes that behavior for `$container->import()`. *Now, all extension configurations encountered in your external file will be prepended instead. BUT, this will only happen here, at this moment, during the `prependExtension()` method.*Of course, this little behavior change is a "BC break". However, it is a behavior that makes more sense than the previous one, enabling the usage of `ContainerConfigurator::import()` here, which was previously ineffective.This capability is also available for `YamlFileLoader`, `XmlFileLoader` and `PhpFileLoader` through a new boolean constructor argument:```phpclass AcmeFooBundle extends AbstractBundle{    public function prependExtension(ContainerConfigurator $container, ContainerBuilder $builder): void    {        // Before        // - It can't be used for prepending config purposes        // After        $loader = new YamlFileLoader($builder, new FileLocator(__DIR__.'/../config/'), prepend: true);        $loader->load('doctrine.yaml'); // now it prepends extension configs as default behavior        // or        $loader->import('prepend/*.yaml');    }}```These changes only affect the loading strategy for extension configs; everything else keeps working as before.Cheers!Commits-------6ffd70662e prepend extension configs with file loaders

…h file loaders (yceruto)This PR was merged into the 7.1 branch.Discussion----------[DependencyInjection] Prepending extension configs with file loaders| Q             | A| ------------- | ---| Branch?       | 7.1| Bug fix?      | no| New feature?  | yes| Deprecations? | no| Issues        | Fix #52789| License       | MITsymfony/symfony#52636 continuation.This is another try to simplify even more the prepending extension config strategy for Bundles and Extensions.Feature: "Import and prepend an extension configuration from an external YAML, XML or PHP file"> Useful when you need to pre-configure some functionalities in your app, such as mapping some DBAL types provided by your bundle, or simply pre-configuring some default values automatically when your bundle is installed, without losing the ability to override them if desired in userland.```phpclass AcmeFooBundle extends AbstractBundle{    public function prependExtension(ContainerConfigurator $container, ContainerBuilder $builder): void    {        // Before        $config = Yaml::parse(file_get_contents(__DIR__.'/../config/doctrine.yaml'));        $builder->prependExtensionConfig('doctrine', $config['doctrine']);        // After        $container->import('../config/doctrine.yaml');    }}```The "Before" section is limited to importing/parsing this kind of configuration by hand; it doesn't support features like `when@env`, recursive importing, or defining parameters/services in the same file. Further, you can't simply use `ContainerConfigurator::import()` or any `*FileLoader::load()` here, as they will append the extension config instead of prepending it, defeating the prepend method purpose and breaking your app's config strategy. Thus, you are forced to use `$builder->prependExtensionConfig()` as the only way.> This is because if you append any extension config using `$container->import()`, then you won't be able to change that config in your app as it's merged with priority. If anyone is doing that currently, it shouldn't be intentional.Therefore, the "After" proposal changes that behavior for `$container->import()`. *Now, all extension configurations encountered in your external file will be prepended instead. BUT, this will only happen here, at this moment, during the `prependExtension()` method.*Of course, this little behavior change is a "BC break". However, it is a behavior that makes more sense than the previous one, enabling the usage of `ContainerConfigurator::import()` here, which was previously ineffective.This capability is also available for `YamlFileLoader`, `XmlFileLoader` and `PhpFileLoader` through a new boolean constructor argument:```phpclass AcmeFooBundle extends AbstractBundle{    public function prependExtension(ContainerConfigurator $container, ContainerBuilder $builder): void    {        // Before        // - It can't be used for prepending config purposes        // After        $loader = new YamlFileLoader($builder, new FileLocator(__DIR__.'/../config/'), prepend: true);        $loader->load('doctrine.yaml'); // now it prepends extension configs as default behavior        // or        $loader->import('prepend/*.yaml');    }}```These changes only affect the loading strategy for extension configs; everything else keeps working as before.Cheers!Commits-------6ffd70662e prepend extension configs with file loaders