This is by design. A prototyped array is still part of the semantic configuration tree.

The reason behind this is env vars can be any value during runtime, but the tree needs to be validated during compile time.

In this case it would be:

swiftmailer:
    delivery_addresses:
        - '%env(MAILER_DELIVERY_ADDRESS_1)%'
        - '%env(MAILER_DELIVERY_ADDRESS_2)%'

I am closing here as this is the expected behaviour.

@ro0NL it wouldn't work. This is equal to [null], so count of delivery_addressess is bigger than 0.
See https://github.com/symfony/swiftmailer-bundle/blob/master/DependencyInjection/SwiftmailerExtension.php#L336

Looks like env should be convenient replacement of parameters.yml but in fact it is not.

environment variables and parameters have different usecases, so i wouldnt call it a replacement per se. Let alone to blindly update all parameters to env vars.

You say this doesnt work?

swiftmailer:
    delivery_addresses:
        - '%env(MAILER_DELIVERY_ADDRESS_1)%'
        - '%env(MAILER_DELIVERY_ADDRESS_2)%'

I try to say that when yours config will be converted to php array it become [null, null]. There is two members. null and null. Count of such array is 2 not 0.

Thus Swiftmailer will try to send all email not to real users, but to this two emails.

I should either pass null instead of array, or array with zero members. Only then swiftmailer will send email to real users.

On my production server config should be equals to:

swiftmailer:
    delivery_addresses: null
or
swiftmailer:
    delivery_addresses: []

On my staging server config should be equals to:

swiftmailer:
    delivery_addresses:
        - test@email

With env var it is impossible to do so.

@ln-e i got it :) thx. Currently this is impossible indeed, but it can be done by prepending a dynamic config in php ...

A permanent solution could be to expand the env syntax, in an effort to expose more type information.

%env(string[]:json:MAILER_DELIVERY_ADDRESSES)%

Here string is an existing prefix and the special [] notation would tell us this is an array of strings, which is compatible with the swiftmailer.delivery_addresses node. Moreover, it would actually be validated as such during runtime.

cc @nicolas-grekas

Or we patch the bundle to make it accept an array and deal with it in a factory. I'd prefer this over adding more complexity.

Is there any proposed solution that would allow the use of the json processor?

Using :

swiftmailer:
    delivery_addresses:
        - '%env(MAILER_DELIVERY_ADDRESS_1)%'
        - '%env(MAILER_DELIVERY_ADDRESS_2)%'

Is actually unusable if I wish to have 2 emails in one environment and 4 in another one. The dynamism allowed by the arrayNode is broken.

Thank you!

Hi guys,

I've managed to make the code work manually overwriting :

// In Symfony\Component\Config\Definition\ArrayNode
    /**
     * {@inheritdoc}
     */
    protected function allowPlaceholders(): bool
    {
        return false;
    }

// to 


    /**
     * {@inheritdoc}
     */
    protected function allowPlaceholders(): bool
    {
        return true;
    }

No errors were thrown.

Can anyone shed some light on why was it set to false and, maybe, the negative repercussions to setting it to "true"?

because it would only work "by chance", e.g. if the env is set correctly. At this point you can change the env to any value and it would always pass config validation.

See #29270 for a different approach.

is there any progress with this issue?

Regardless of how the configuration tree of the swiftmailer bundle is set up: what is the correct way to allow dynamic values for a scalar array node in the configuration tree of your own bundle? I am unable to figure out the correct way to do this.

I've just spent ages trying to work out why the example in the docs isn't working. Has anything changed in the past 2 years to allow this to work somehow? If not, might be worth updating the docs to remove this as a bad example to save others time?

Being new to Symfony, initially got excited by the power of the config syntax only to run into completely artificial limitations on where in the config structure said syntax is allowed and where it is arbitrarily not.

Use Case

The intent is to pass driver options to Doctrine DBAL:

doctrine:
    dbal:
        url: '%env(resolve:DATABASE_URL)%'
        driver: '%env(string:DATABASE_DRIVER)%'
        options: '%env(json:DATABASE_DRIVER_OPTIONS)%'

By design, each driver comes with a unique set of options of virtually arbitrary format: key-value pairs mixed with flags.

Unfortunately, this syntax is not allowed in such completely reasonable situations:

A dynamic value is not compatible with a "Symfony\Component\Config\Definition\PrototypedArrayNode" node type at path "doctrine.dbal.connections.default.options".

Workaround

A patch proposed by @dtfafard can be used as a workaround:

composer require cweagans/composer-patches

composer.json

{
    "extra": {
        "patches": {
            "symfony/config": {
                "Dynamic config values": "patches/symfony-config.patch"
            }
        }
    }
}

patches/symfony-config.patch

diff --git a/vendor/symfony/config/Definition/ArrayNode.php b/vendor/symfony/config/Definition/ArrayNode.php
index 76b811c..14d4565 100644
--- a/vendor/symfony/config/Definition/ArrayNode.php
+++ b/vendor/symfony/config/Definition/ArrayNode.php
@@ -397,6 +397,6 @@ class ArrayNode extends BaseNode implements PrototypeNodeInterface
      */
     protected function allowPlaceholders(): bool
     {
-        return false;
+        return true;
     }
 }

composer install

Proposal

How about extending the env() syntax to explicitly allow misc data structure?

%env(mixed:json:DATABASE_DRIVER_OPTIONS)%

There're numerous reports of this config inflexibility closed as "explained" or "by design" citing compile-time validation of the config format. While the validation is valuable, it's a pity to artificially restrict applications of such a powerful syntax.