Nested structs are flattened for caarlos0 targets
Tested Version: 1.8.0
Nested structs (both named and anonymous) are not converted to children when using caarlos0 as a target.
For example, with this config:
package main
//go:generate go run ../../ -output doc_cleanenv.txt -target cleanenv -format plaintext
//go:generate go run ../../ -output doc_caarlos0.txt -target caarlos0 -format plaintext
type Config struct {
// Hosts name of hosts to listen on.
Hosts []string `env:"HOST,required" env-required:"true" env-separator:";" envSeparator:";"`
// Port to listen on.
Port int `env:"PORT"`
// Debug mode enabled.
Debug bool `env:"DEBUG" env-default:"false" envDefault:"false"`
// Timeouts configuration.
Timeouts struct {
// Read timeout.
Read int `env:"READ" env-default:"10" envDefault:"10"`
// Write timeout.
Write int `env:"WRITE" env-default:"10" envDefault:"10"`
} `env-prefix:"TIMEOUT_" envPrefix:"TIMEOUT_"`
Next NextConfig `env-prefix:"NEXT_" envPrefix:"NEXT_"`
}
type NextConfig struct {
// Mount is a mount point.
Mount string `env:"MOUNT,required" env-required:"true"`
}
The generated cleanenv file:
Environment Variables
## Config
* `HOST` (separated by `;`, required) - Hosts name of hosts to listen on.
* `PORT` - Port to listen on.
* `DEBUG` (default: `false`) - Debug mode enabled.
* Timeouts configuration.
* `TIMEOUT_READ` (default: `10`) - Read timeout.
* `TIMEOUT_WRITE` (default: `10`) - Write timeout.
*
* `NEXT_MOUNT` (required) - Mount is a mount point.
The generated caarlos0 file:
Environment Variables
## Config
* `HOST` (separated by `;`, required) - Hosts name of hosts to listen on.
* `PORT` - Port to listen on.
* `DEBUG` (default: `false`) - Debug mode enabled.
* `TIMEOUT_READ` (default: `10`) - Read timeout.
* `TIMEOUT_WRITE` (default: `10`) - Write timeout.
* `NEXT_MOUNT` (required) - Mount is a mount point.
The cleanenv target has the nested structs correctly handled and indented, while the caarlos0 output has all values on the same level of indentation.
Retaining the parent-child relationship would be good as that makes the hierarchy clear at a single glance.
@g4s8, I looked into this a bit and it stems from how the FieldInfo Names get generated.
The cleanenv decoding always sets the names to a slice which has exactly one element.
On the other hand, The caarlos0 decoding sets the names dynamically, and it can sometimes be empty.
For cases where the names are empty, the children are returned as standalone items.
Updating the caarlos0 decoding process to set the names to a single-element slice when they are empty fixes this, but I can't tell if that introduces any unwanted side-effects. You should have a better context of the right approach to take here.