feat: being able to add env name for a specific field

[mojixcoder]

Hello and thanks for your great package.
I have a specific use case in which env var is using another names which is different with the name generated by the fig for that field.

Can we add a new feature to achieve this.

Something like this:

type Config struct {
    Field int `fig:"field" env:"DIFFERENT_KEY"`	
}

This way, the config is loaded from a file using the current approach. But if the DIFFERENT_KEY env is set, its value will be used for this field.

[mojixcoder]

If you think that’s ok, I can work on it.

[kkyr]

Hi @mojixcoder, when loading from the environment using fig, it's important to consider the hierarchical nature of structs, especially when dealing with nested structs. Consider the following example:

type Config struct {
    Inner struct {
        Field int `fig:"field"`
    } `fig:"inner"`
}

In this scenario, fig would search for an environment variable named INNER_FIELD to populate the Field within the Inner struct, assuming no specific prefix has been set.

Coming back to your use case, are you looking to override the entire composite key derived from the nested structure, or are you only interested in modifying the key at the specific level of the nested field?

[mojixcoder]

The problem is that usually keys in yaml files are different from env names and I want to be able to read config from both of them.
For example see this:

type Config struct {
    Jeager struct {
        ServiceName string `fig:"serviceName" env:"JAEGER_SERVICE_NAME"`
    } `fig:"jaeger"`
}

If I want to load this variable using fig, It should be jaeger.serviceName for yaml files which is fine. but if I want to load it from env it will be JAEGER_SERVICENAME, but I want the key to be JAEGER_SERVICE_NAME (looks better as env variable).
That's why I was looking for a way to separate env variable names.

[kkyr]

I'm hesitant on adding a new struct tag, as it increases cognitive complexity and introduces potential confusion regarding the precedence of various struct tags.

An alternative could involve specifying an environment key creation strategy that fig uses to construct environment variable keys from struct fields. By default, fig transforms a field name (or its tag) entirely into uppercase, turning serviceName into SERVICENAME. However, introducing an option for a different strategy that for instance would use word splitting with underscores, while also converting to uppercase, could be beneficial. This would mean serviceName would be transformed into SERVICE_NAME instead.

This approach maintains simplicity for fig users and adds flexibility in how environment variable names are constructed. What do you think?

[mojixcoder]

This approach looks good to me.
My only concern is about abbreviation words like USA turning into u_s_a.
Overall it looks good.

[kkyr]

You should iterate and only split when an uppercase letter is preceded by a lowercase letter, so in your example USA would remain USA.