-
-
Notifications
You must be signed in to change notification settings - Fork 9.6k
[DependencyInjection] Add #[When(env: 'foo')]
to skip autoregistering a class when the env doesn't match
#40782
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
src/Symfony/Component/DependencyInjection/Tests/Fixtures/Prototype/Foo.php
Show resolved
Hide resolved
Would it make sense to also take the debug flag into account? #[When(debug: true)] class When
{
public function __construct(
public ?string $environment = null,
public ?bool $debug = null,
) {
}
} |
I considered adding debug when working on #40214 but in the end, this I decided against. The reason is that we have no use case for loading configuration conditionally based on debug/non-debug without corresponding complex logic. debug is useful for two things: logic in DI extensions, and runtime logic of services. Adding it here would increase complexity by a lot for no practical benefit. About |
Oh, that slipped me. Yes, I would be very much in favor of changing the property to |
Argh, I very much prefer |
I'm also prefer |
👍🏻 |
#[When(env: 'foo')]
to skip autoregistering a class when the env doesn't match
…he env doesn't match
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like this now! But... one last question :). Can we (someone) put out a concrete use case for this? I checked our codebase, and we don't do this very often. But I also might be neglecting a nice thing that "conditionally registering a service in an environment" allows me to do.
Thanks!
We do this very often actually, but we do this through bundles, which are the parts that are conditionally loaded by env. In apps, there are no bundles usually, and ppl have to resort to writing explicit config, by 1. excluding the corresponding classes from discovery and 2. loading them only in the appropriate env. I've talked to several ppl that do this. A typical example is an event listener that should be enabled only for prod/dev/etc. |
@weaverryan Here is a real use case from a real project, defining a command only for the dev env: I define my services in PHP files in // Kernel.php
$container->import(__DIR__.'/../config/services/*.php');
$container->import(__DIR__.'/../config/{services}/'.$this->environment.'/*.php'); Before: // config/services/commands.php
$services
->load(
'App\\Command\\',
'../../src/Command'
)
->exclude([
'../../src/Command/Dev',
]); //config/services/dev/commands.php
$services
->load(
'App\\Command\\Dev\\',
'../../../src/Command/Dev'
); After: // config/services/commands.php
$services
->load(
'App\\Command\\',
'../../src/Command'
); // src/Command/Dev/MyDevCommand.php
#[When(env: 'dev')]
final class MyDevCommand extends Command Logically, I won't need those env sub directories anymore. |
This is a follow up of #40214, in order to conditionally auto-register classes.
By adding a
#[When(env: prod)]
annotation on a class, one can tell that a class should be skipped when the current env doesn't match the one declared in the attribute.This saves from writing similar conditional configuration by using the per-env
services_prod.yaml
convention (+corresponding exclusion fromservices.yaml
), or some logic in the Kernel.