WDYT @weaverryan ?
by "disabling" i mean "remove services from container"
but it is a little bit tricky, because we should also disable some routes, thus we have to create a custom routing loader i guess

maybe not worth the pain to do that... 🤔

Indeed. If we disable things based on the configuration of a different service, it would need to be done in a compiler pass. But it is a nice thing to do. So:

a) Probably let's not worry about routes. But I guess we could at least write those controllers so that if you try to access them, they give you a good error about needing the failure transport to be configured.

b) Removing the services would be nice, in a compiler pass. And, we may (?) not need to remove many. What I mean is, we would just need to remove any event listeners and any service we use directly in those failure controllers. If there are some additional, lower-level services that these other services depend on, we don't really need to remove those, as the container would remove them automatically because we removed all services using them, if that makes sene :p

but the problem is: if i remove from the container the services which are injected in the controllers, i may have an error when building the container, won't I ?

Yep, you'll need to make those services optional - so with the on-invalid-null and = null on the arguments to the constructor. But you could then immediately (in the constructor) throw an exception of the injected services are null.

It's not super clean... but it would be nice to clean things up.

or i create another controller which handles these routes when failure transport is not configured
(and i disable original controllers)

or i create the custom route loader. I've never done that, but i'm sure that's not that complicated

I like both of these ideas :). You can try the custom route loader... though... at the end of the day, I kinda prefer the user to be able to see the routes they're importing inside their app versus them being magically loaded somehow (and this will allow them to control the prefix - not sure how that works with custom route loaders)

ok, i agree, that's better if the user can see easily the routes we're adding; go for this solution!

btw, you can add a prefix even with a custom route loader
for example: https://github.com/symfony/recipes/blob/master/api-platform/core/2.1/config/routes/api_platform.yaml