Why are default values written to the config file?

[thallgren]

When the config file is written out, the default values are written out too. Thus, the fact that they represent defaults, and hence can be overridden, is lost. This means that a binary where a default is modified (say, by an upgrade), will no longer get its default although no one ever added the value to the config.

So my question is, why are default values written out? If the config is written, I end up in a situation where this doc from SetDefault is no longer true:

// Default only used when no value is provided by the user via flag, config or ENV.

[hexvalid]

The write methods serialize the effective configuration, including defaults. In Viper v1.21.0, marshalWriter calls AllSettings(); it does not retain each value's original source when producing the file. See the implementation.

Your upgrade concern follows directly from that: after a default is written and the file is read again, it is a config-file value, which has higher precedence than a newly changed default. I verified this with a default of 30, a write/reload, and then a new default of 60: the effective value remained 30.

To preserve the distinction, keep the persisted configuration separate from the runtime configuration:

persisted := viper.New()
persisted.SetConfigFile("config.yaml")
if err := persisted.ReadInConfig(); err != nil {
    return err
}

runtimeConfig := viper.New()
runtimeConfig.SetDefault("timeout", 60)
if err := runtimeConfig.MergeConfigMap(persisted.AllSettings()); err != nil {
    return err
}

// Persist only an explicit user edit.
persisted.Set("name", "changed")
return persisted.WriteConfig()

Use runtimeConfig for effective values, and add defaults/environment/flag bindings there. Apply persistent user edits to persisted and update/rebuild the runtime view as needed.

Comparing values against defaults before saving is insufficient: a user may explicitly choose a value that happens to equal today's default. Separating the two configurations preserves that intent.

[thallgren]

I would argue that values none of our customers have ever set or cared about, shouldn't be persisted in our customers config data. Persisting such values has the undesired result that our customer base suddenly have stipulated values that they never cared about in the first place, and that our software updates cannot cannot change.