I kinda get the problem you're trying to solve but IMO the solution is a bit unclear. Are those auto excluded channels excluded from all handlers, or only those with exclusion lists? I think it's the latter but I don't really see why..

Also name nitpick, perhaps default_excluded_channels instead of auto. Having default_channels might be even more sensible so you can pick or exclude like the rest of channels, and it wouldn't be an inverted option.

I kinda get the problem you're trying to solve but IMO the solution is a bit unclear. Are those auto excluded channels excluded from all handlers, or only those with exclusion lists? I think it's the latter but I don't really see why..

Hi, they're excluded only from handlers with an exclusion list. I don't think it would make since for the channels to be excluded from inclusion lists since the channels in those lists are explicitly added through the configuration. I'm not sure how to make this a little more clear.

Also name nitpick, perhaps default_excluded_channels instead of auto.

Your suggestion makes sense, I've updated the name.

Having default_channels might be even more sensible so you can pick or exclude like the rest of channels, and it wouldn't be an inverted option.

Just to see if I've understood you correctly, the default_channels option would be a list of channels to be included to or excluded from every handler. If that's the idea, I like it a lot. How would this work in terms of precedence though? Here's my guess:

1. if default_channels is an exclusion list and the handlers channels list is an inclusion list, or, default_channels is an inclusion list and the handlers channels list is an exclusion list, the handlers list would take precedence:

   monolog:
       default_channels: [ "!one", "!two", "!three" ]
       handlers:
           main:
               # ...
               channels: [ "one", "four" ] # final list: ["one", "four"]

   monolog:
       default_channels: [ "one", "two", "three" ]
       handlers:
           main:
               # ...
               channels: [ "!one", "!four" ] # final list: ["!one", "!four"]

2. if both default_channels and the handlers channels list are exclusion lists, or, both are inclusion lists, the lists would get merged:

   monolog:
       default_channels: [ "!one", "!two" ]
       handlers:
           main:
               # ...
               channels: [ "!two", "!three", "!four" ] # final list: ["!one", "!two", "!three", "!four"]

   monolog:
       default_channels: [ "one", "two" ]
       handlers:
           main:
               # ...
               channels: [ "two", "three", "four" ] # final list: ["one", "two", "three", "four"]

In other words, if the lists are the same type, they'd get merged, otherwise, if they're not, the handlers channels list would take precedance.

Also, what about cases such as whitelisting a default excluded channel on some handler or blacklisting a default included one on another? Should there be some special syntax for that, eg my !! proposal:

monolog:
    default_channels: [ "!one", "!two" ]
    handlers:
        main:
            # ...
            channels: [ "!!two", "!three", "!four" ] # final list: ["!one", "!three", "!four"]

or would adding a use_default_channels option make more sense. The option would be true by default, but could be set to false on a per-handler basis:

monolog:
    default_channels: [ "!one", "!two" ]
    handlers:
        main:
            # ...
            use_default_channels: false
            channels: [ "!one", "!three", "!four" ] # final list: ["!one", "!three", "!four"]

@Seldaek Please let me know your thoughts on this and I'll update the PR accordingly.

I've updated the PR according to my proposal.

It seems complex to understand and perhaps a little too specific for something that can be solved with an array_merge using the PHP configuration format.

<?php

use Symfony\Config\MonologConfig;

return static function (MonologConfig $monolog) {
    $defaultChannels = ['!one', '!two', '!three'];

    $monolog->handlers()->main()
        ->type('fingers_crossed')
        ->actionLevel('error')
        ->handler('nested')
        ->channels($defaultChannels);

    $monolog->handlers()->nested()
        ->type('stream')
        ->path('php://stderr')
        ->level('debug')
        ->formatter('monolog.formatter.json');

    $monolog->handlers()->console()
        ->type('console')
        ->processPsr3Messages(false)
        ->channels(['!event', '!doctrine', ...$defaultChannels]);
};

@GromNaN You make a good point. This PR was opened with YAML in mind. While array_merge() works fine with PHP config, YAML doesn't have a similar option. While this approach works with all config formats, I agree it's a bit complex. I'm fine with closing it if you feel it's not worth it.

The fact that we need a new use_default_channels option is a clear signal that it's too complex to apprehend. PHP configuration is a way to go.

Thank you for your understanding.