Add support for when@ in case bundle imports yaml configuration #63489
-
DescriptionIt's currently very confusing and leads to frustration when certain features do not work depending on what context you are in. For example, when you're in an application/userland, you can use Given a bundle with a build method as such: class MyBundle extends AbstractBundle
{
public function build(ContainerBuilder $container): void
{
/** @var string $environment */
$environment = $container->getParameter('kernel.environment');
$configDir = $this->getConfigDir();
$locator = new FileLocator($configDir);
$resolver = new LoaderResolver([
new YamlFileLoader($container, $locator),
new GlobFileLoader($container, $locator),
new DirectoryLoader($container, $locator),
new ClosureLoader($container),
]);
$configLoader = new DelegatingLoader($resolver);
$configLoader->load("$configDir/{packages}/*.{yaml,yml,php}", 'glob');
$configLoader->load("$configDir/{packages}/$environment/*.{yaml,yml,php}", 'glob');
}
protected function getConfigDir(): string
{
return $this->getPath() . '/config';
}
}You'd expect ExampleJust being able to use the same yaml configuration including when@ keys when loading a config file from a bundle. framework:
cache:
pools:
cache.app:
adapter: cache.adapter.system
when@prod:
cache:
framework:
pools:
cache.app:
adapters:
- cache.adapter.apcu
- cache.adapter.valkey
default_lifetime: 86400 |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment · 1 reply
-
|
It doesn't work because you don't pass all necessary arguments to the loaders, see then $env one esp. |
Beta Was this translation helpful? Give feedback.
-
|
Oh awesome, seems like we were just missing the I personally do not see the difference between us explicitly calling load on every file we want to add, or just using a glob pattern to automatically grab all files. I largely distaste the "best practices" guides when they go 2 separate ways for apps and for bundles. The main point we always hammer about in our industry when it comes to code style is standardisation and consistency. Many have told me in the past that this "isn't best practice". But it works, it's fully supported, it's exactly the way we'd do it in apps, and it produces exactly the same result as configuring each file individually or directly in the build function. Additionally, this is all done on build time, so no performance issues. Up until this day, nobody has been able to give us a good argument besides "it's not best practice". We're also not the typical bundle. Our bundle is a full "platform" or "subframework". We don't expect users to install our bundle alongside other Symfony bundles (besides those we listed as dependencies) or in a standard Symfony application. We use it more like Shopware, with Symfony as the backbone for wiring it all together. Our custom flex repo is highly customised and rips out most of the standard framework configuration so we can provide it through our bundle instead. |
Beta Was this translation helpful? Give feedback.
It doesn't work because you don't pass all necessary arguments to the loaders, see then $env one esp.
Also: the snippet you give here looks like bad practice: a bundle should have a fixed set of config files.
Sniffing around with a glob pattern fits apps, but the best practice for bundles is to use only the php format also.