[RFC]: Secrets in environment variable placeholders about untool

[herschel666]

I mostly agree with @ZauberNerd here. I would add though that version 4 makes it too easy to overwrite the setting and thus provides kind of a foot gun. I also right now can't think of a situation where a preset would want to change the visibility set by a previous preset.

So I'd be in favour of variant 3.

It still provides a way to change the setting, which could be applied by users and preset authors alike. So coming from a preset that looks like that…

{
  "secret": "[SUPER_SECRET]"
}

…ppl could expose the value like this…

{
  "secret": "[SUPER_SECRET]",
  "meDontCares": "<secret>",
  "whitelist_array": ["meDontCares"],
}

[dmbch]

Another option would be to introduce an object (e.g. serverOnly) that would be merged and generally handled separately and that could hold the appropriate props and hidden from the client.

That being said, my personal preference would be option 1 or 2..: these appear to be most aligned with framework and ecosystem standards and conventions.

[ZauberNerd]

I would prefer to white-list keys that should go to the client-side instead of black-listing them (which would be kind of the case with serverOnly).

I don't like variant 2 and 5 because then a user could overwrite the default value that comes from a preset and would lose the visibility settings.

With variant 1 we would need to change our code whenever the visibility changes (or build some complicated getter/proxy stuff around it), therefore I would prefer variant 3 or 4.
I think I'm leaning more towards variant 4, because that would allow later presets / the application config to overwrite the visibility of values, but since it will always be merged it is safe by default.

[dmbch]

If we did decide to go with variant 3, we would have to deal with that array like with mixins - and that would be breaking abstractions, unfortunately: we would be introducing knowledge about the distinction between client and server to @untool/core - and that is something it is not really supposed to know about.

I would therefore prefer going with variant 4 and implement it in @untool/webpack.

[herschel666]

I consider this decided & done!